Из другого источника: «Вообще говоря, миф о плоской Земле возник в XIX веке. Виной тому — полухудожественный роман Вашингтона Ирвинга «Жизнь и путешествия Христофора Колумба» (1828), где автор ошибочно написал, что Колумб отправился в свое знаменитое путешествие, чтобы доказать, что Земля — круглая, а не плоская, как якобы считалось в то время.»
Ну всё равно начинается та же песня — а если гуглопочта, а если не гуглопочта, а если линукс, а если макинтош, а если политика компании позволяет иметь только текстовый браузер lynx и архиватор zip…
Я в целом думаю, что надо относиться друг к другу терпимее и не призывать сжечь ведьму, если она прислала rar/docx/pdf/etc. Сейчас в мире такой зоопарк систем и ситуаций, что практически невозможно стопроцентно сделать второй стороне удобно. Разве что обмениваться ссылками на plain ASCII документы.
Когда мне присылают, например, не самый мейнстримный, но всё равно не экзотический RTF, я не задаюсь вопросом, почему так. Я ищу способ его прочесть, и исхожу из предпосылки, что отправитель вовсе не желает мне зла, просто в его среде даже мысли не возникает, что у получателя могут быть с rtf какие-либо проблемы. И уж точно не буду ставить диагноз человеку по формату присланного документа или домену его почтового сервера.
Понимаю. Но в целом (не применительно к вашей ситуации) считаю проблему надуманной — ладно rar, а как же 7zip? Или нам игнорировать последние 20 лет развития средств компрессии только из-за того, что где-то с их адаптацией сложности?
Не могу сказать про *nix, а вот на Windows, извините, PDF из коробки не читается, и на этом основании я тоже мог бы советовать воздержаться от использования PDF, т.к. у меня «бизнес-процесс», и смотрелку мне никак не установить. Шлите plain-text.
Усваивать полезные фразы гораздо проще, если они не тонут в информационном шуме. ОК, может, с «тонут» я и перегнул палку, но уж личные особенности восприятия необязательно было перечислять, потому что nobody cares. А я, может, не воспринимаю CV, написанные шрифтом Times New Roman, ибо скучно.
Да какая вам как получателю разница? Я вот использую RAR, потому что привык и мне удобно. Если 7zip можно, то должно быть пофигу, т.к. распаковщик 7zip поддерживает и формат rar. Что ж теперь, отказывать соискателю по религиозным причинам («использует ненужный софт»)?
Я понимаю, в чём смысл статей в стиле «общие разумные правила оформления резюме», но если разговор переходит в плоскость личных приколов конкретного читающего, какие выводы отсюда можно сделать? Иными словами, в чём ценность прочитанного? Все и так понимают, что у каждого человека свои тараканы. Вот вы любите PDF и GMail, но не любите Mail.ru и RAR. Откуда же я, потенциальный соискатель, могу это знать? У меня же нет хрустального шара. А 7zip и tar вы любите?
Кстати, вот про rar окончательно задело — сначала нам говорят, что gmail, дескать, по-гиковски, а mail.ru — не по-гиковски, а потом начинают придираться к форматам архивов, хотя, уверен, у любого более-менее грамотного пользователя стоит архиватор, который распакует что угодно, кроме совсем уж экзотических форматов. Мне вот пофигу, в каком архиве документ — двойной щелчок, и он открылся.
Ну вы же сами сказали — потому что нет 2 ляма долларов на адвокатов.
Суды, допустим, внятные, но любое разбирательство стоит денег. Допустим, компания А говорит, что у неё есть патент на некоторую технологию, а злокозненная корпорация Б (владелец тысяч патентов) утверждает, что технология также покрыта её патентом. Соответственно, будет разбирательство, и даже если правда 100% на стороне А, надо иметь лишние пару лямов, чтобы эту правду доказать.
А мне вот интересно, как «ситуация 1» отличается при наличии патентов у Пети, и не придётся ли всё равно выложить 2 млн долларов (если корпорация зла говорит, что таки нарушил, несмотря на наличие своего патента).
Конечно, поддерживаю. Но в общем-то всё это вопрос нюансов.
Рассмотрим вот такую простую задачу: с клавиатуры вводится массив чисел (число-enter-число-enter...), пока не будет введён нуль. Далее этот массив каким-то образом обрабатывается.
В чистом C эта банальщина реализуется очень трудно (т.к. нет автоматически растущих массивов). Получается, либо надо выделять фиксированный блок на N элементов (чему мы учим детей??? этому чудовищному стилю, где возможен buffer overflow?), либо реализовывать поведение наподобие того, что есть в std::vector.
Получается, что да, технически мы имеем сложную задачу, но логически это минимальный юнит кода, чисто служебный. Аналогично, есть задачи, где ассоциативный массив напрашивается, но писать его самостоятельно (даже в учебных целях) никто не будет, т.к. реализация займёт 50% всего кода. Игра не стоит свеч. Вот и будут делать линейный поиск.
Таким образом, получается, что дети не учатся выбирать наиболее эффективную структуру данных для своей задачи. Если реализация тоже ложится на их плечи, конечно, будет выбрано наиболее простое решение. Да ё-моё, я сам почти всегда пишу std::map, даже если правильнее было бы взять хэш-таблицу, но как стандарт она появилась только в C++11.
Мы вступаем на очень тонкий лёд. Безусловно, они должны понимать, как работает структура данных, но реализовывать всё самим — а где та грань? Почему бы им самим не реализовать, например, функцию синуса — или вы тоже их это заставляете? Я думаю, что любой человек должен прежде всего знать наперечёт все базовые структуры данных, а их реализация — вопрос уже следующий.
Ученики всё равно не могут всё знать. Вот спросите, как в компьютере вычисляется логарифм или квадратный корень — уверен, далеко не все ответят.
По поводу «удосужились — не удосужились» — вот в Паскале есть встроенные операции со множествами, а в Си нет. Не удосужились :)
В C++ ассоциативные массивы есть. Я не знаю, что такое STL (dumb mode on) — если вы заглянете в Стандарт C++, то увидите там упоминание std::map наряду с std::max(), например, а слова STL вы не увидите нигде. То, что исторически map взят из библиотеки STL, не имеет никакого значения. Я тоже могу сказать, что в C нет поддержки файлов — она есть в stdio.h.
Ну, просто Java — язык агрессивно объектный, надо взять что-то менее заставляющее принудительно пользоваться объектами.
Я исхожу из того, что недостатки C ещё более существенны и формируют достаточно однобокий взгляд на программирование. Конечно, как преподаватель вы можете его скорректировать, но это приходится делать явным образом.
Например, в C есть массивы, но нет ассоциативных массивов. А ведь с точки зрения логики в чём разница? Там сопоставляют структуру целочисленному индексу, а здесь один объект другому. Словарь, телефонный справочник.
В C его нет лишь потому, что авторы не удосужились его добавить. А у школьника возникает сразу же деление структур данных на «встроенные в C» и «какие-то-другие-из-сложного-учебника», которые надо либо подключать в сторонних библиотеках, либо писать самому.
Если программирование — это структуры данных и алгоритмы, то в C всё очень скверно со структурами данных, и если уж изучать программирование на примере C, то параллельно надо читать отдельную книжку по структурам.
Ха, ну так видите — дело не в типизации, а в языке. Вот в C# программа с неинициализированной переменной не откомпилируется.
Я думаю, что вы в целом несправедливо проводите разграничение по линии типизации.
Да, C — язык со статической типизацией, но его типизация позволяет выполнять дивнейшие фортели.
В то время как более современные языки с динамической типизацией могут быть гораздо строже к выполняемым конструкциям.
Всё зависит от конкретного языка.
Я в целом думаю, что надо относиться друг к другу терпимее и не призывать сжечь ведьму, если она прислала rar/docx/pdf/etc. Сейчас в мире такой зоопарк систем и ситуаций, что практически невозможно стопроцентно сделать второй стороне удобно. Разве что обмениваться ссылками на plain ASCII документы.
Когда мне присылают, например, не самый мейнстримный, но всё равно не экзотический RTF, я не задаюсь вопросом, почему так. Я ищу способ его прочесть, и исхожу из предпосылки, что отправитель вовсе не желает мне зла, просто в его среде даже мысли не возникает, что у получателя могут быть с rtf какие-либо проблемы. И уж точно не буду ставить диагноз человеку по формату присланного документа или домену его почтового сервера.
Не могу сказать про *nix, а вот на Windows, извините, PDF из коробки не читается, и на этом основании я тоже мог бы советовать воздержаться от использования PDF, т.к. у меня «бизнес-процесс», и смотрелку мне никак не установить. Шлите plain-text.
«Under Debian or Ubuntu Linux, you need to type apt-get command as follows to install unrar program:
# apt-get install unrar»
Т.е. всё есть.
Кстати, вот про rar окончательно задело — сначала нам говорят, что gmail, дескать, по-гиковски, а mail.ru — не по-гиковски, а потом начинают придираться к форматам архивов, хотя, уверен, у любого более-менее грамотного пользователя стоит архиватор, который распакует что угодно, кроме совсем уж экзотических форматов. Мне вот пофигу, в каком архиве документ — двойной щелчок, и он открылся.
Суды, допустим, внятные, но любое разбирательство стоит денег. Допустим, компания А говорит, что у неё есть патент на некоторую технологию, а злокозненная корпорация Б (владелец тысяч патентов) утверждает, что технология также покрыта её патентом. Соответственно, будет разбирательство, и даже если правда 100% на стороне А, надо иметь лишние пару лямов, чтобы эту правду доказать.
Рассмотрим вот такую простую задачу: с клавиатуры вводится массив чисел (число-enter-число-enter...), пока не будет введён нуль. Далее этот массив каким-то образом обрабатывается.
В чистом C эта банальщина реализуется очень трудно (т.к. нет автоматически растущих массивов). Получается, либо надо выделять фиксированный блок на N элементов (чему мы учим детей??? этому чудовищному стилю, где возможен buffer overflow?), либо реализовывать поведение наподобие того, что есть в std::vector.
Получается, что да, технически мы имеем сложную задачу, но логически это минимальный юнит кода, чисто служебный. Аналогично, есть задачи, где ассоциативный массив напрашивается, но писать его самостоятельно (даже в учебных целях) никто не будет, т.к. реализация займёт 50% всего кода. Игра не стоит свеч. Вот и будут делать линейный поиск.
Таким образом, получается, что дети не учатся выбирать наиболее эффективную структуру данных для своей задачи. Если реализация тоже ложится на их плечи, конечно, будет выбрано наиболее простое решение. Да ё-моё, я сам почти всегда пишу std::map, даже если правильнее было бы взять хэш-таблицу, но как стандарт она появилась только в C++11.
Ученики всё равно не могут всё знать. Вот спросите, как в компьютере вычисляется логарифм или квадратный корень — уверен, далеко не все ответят.
По поводу «удосужились — не удосужились» — вот в Паскале есть встроенные операции со множествами, а в Си нет. Не удосужились :)
В C++ ассоциативные массивы есть. Я не знаю, что такое STL (dumb mode on) — если вы заглянете в Стандарт C++, то увидите там упоминание std::map наряду с std::max(), например, а слова STL вы не увидите нигде. То, что исторически map взят из библиотеки STL, не имеет никакого значения. Я тоже могу сказать, что в C нет поддержки файлов — она есть в stdio.h.
Я исхожу из того, что недостатки C ещё более существенны и формируют достаточно однобокий взгляд на программирование. Конечно, как преподаватель вы можете его скорректировать, но это приходится делать явным образом.
Например, в C есть массивы, но нет ассоциативных массивов. А ведь с точки зрения логики в чём разница? Там сопоставляют структуру целочисленному индексу, а здесь один объект другому. Словарь, телефонный справочник.
В C его нет лишь потому, что авторы не удосужились его добавить. А у школьника возникает сразу же деление структур данных на «встроенные в C» и «какие-то-другие-из-сложного-учебника», которые надо либо подключать в сторонних библиотеках, либо писать самому.
Если программирование — это структуры данных и алгоритмы, то в C всё очень скверно со структурами данных, и если уж изучать программирование на примере C, то параллельно надо читать отдельную книжку по структурам.
По-моему, моя первая компьютерная программа была чем-то вроде:
INPUT name$
PRINT «Hello, »; name$; "!"
Получается, какие-то довольно простые и прикольные вещи скрыты лишь потому, что конкретный язык этого не позволяет.
TXLib — хорошо, но в любом упомянутом мной языке тоже есть хорошие библиотеки.
Я думаю, что вы в целом несправедливо проводите разграничение по линии типизации.
Да, C — язык со статической типизацией, но его типизация позволяет выполнять дивнейшие фортели.
В то время как более современные языки с динамической типизацией могут быть гораздо строже к выполняемым конструкциям.
Всё зависит от конкретного языка.