на мой вопрос «у меня плохая память на имена потому слова „теорема Такого-то Сякого-то“ мне ни о чём не говорят — не могли бы вы сказать о чём она?» преподаватели реагировали всегда вполне благосклонно — при условии, конечно, что я на самом деле знал как доказать эту самую теорему.
Помнится, в коллоидной химии есть формула (не помню чьего имени),
полученная эмпирически. Эта формула — 4х этажная дробь, где много всяких буковок и коэффициентиков. Студенты должны были ее знать, чтобы сдать экзамен на ХФ МГУ :) А в физмат школе, где я учился, мы должны были помнить формулу синуса тройного угла и еще кучу подобного мусора, который можно посмотреть в любом справочнике.
хотя как раз Жизнь ускорить с использованием ассемблера можно изрядно
Который легко может обойти переносимую реализацию по скорости в 2-3 раза, иногда и больше.
А Жизнь можно таким образом в 2-3 раза ускорить? На мой взгляд, это неочевидно. М.б. на 10-20% — более реалистичное ожидание?
Почему я говорю о кусках кода с интринзиками как об «ассемблере»?
Пусть берет, главное, чтобы результат был правильный. Необязательно преподавателю знать все языки.
Разве учителя не должно волновать, что в коде «goto labels[index]^» и подобное? ;) Если преподаватель будет формально смотреть только на результаты работы программы, то такого преподавателя легко обмануть: скачать решение из инета или попросить приятеля решить задачку и идти сдавать, совершенно не понимая, как работает это решение. А вот если преподаватель будет спрашивать по деталям исходного кода, будут видны действительные знания ученика и стиль его кода. Правильно оценить код на совершенно незнакомом языке — проблематично.
Есть задачи, которые компилятор на языке высокого уровня решить лучше человека не сможет, по крайней мере пока
Наверное есть. Это можно предположить, исходя из общих соображений. Вопрос в том, велика ли доля таких задач? Может, это частные случаи, какие-то редкие мелочи, неучтенные при создании компилятора? Если вспомнить компиляторы для IBM 360/370, то там почти со 100%-ой гарантией перенос на ассемблер критического участка кода давал заметный выигрыш. Сейчас, благодаря прогрессу, не всегда очевидно, стоит ли игра свеч, т.е. время на перенос можно потратить много, а выигрыш может оказаться очень небольшим.
думаете люди от нечего делать там целые функции на ассемблере или интрисиками пишут?
На столь общее утверждение существует столь же общее возражение: некоторые люди иногда совершают странные и непонятные стороннему наблюдателю поступки ;) М.б., со времен IBM 360 сложилась традиция какие-то специальные функции на ассемблере писать? ;) Переносили старый код и, недолго думая, все, что на ассемблере, написали на ассемблере. (Я, конечно, несколько утрирую, но в столь общих рассуждениях это неизбежно :)
Я имел ввиду немного другое — неписанные стандарты, кто-то вот решил, что указатели это зло и сказал — в школе будем изучать язык без указателей — это будет стандарт обучения.
Бывают не только глупые/бездарные ученики, но и учителя :)
Зубрить ничего не надо, надо понимать суть, для остального есть справочники
Согласен. Но традиционно, даже в лучших универах, математику и естественные науки изучают путем зубрежки формул, теорем, доказательств и т.д. (А студенты-историки даты зубрят :))
а школьные задачи можно решить на любом языке — пусть ученик сам решает — на сколько он готов выпендриваться. У нас в школе так и было, кто-то писал на Бейсике, кто-то на Паскале, я писал на Си.
А если ученик возьмет совсем экзотический язык, который мало кто знает? Нпр., в моей коллекции есть описания и трансляторы языков T и Dee. Слышали о таких? ;)
А критические участки реализуют на ассемблере по сей день, и если что — я и мои знакомые можем делать на ассемблере код более быстрый, чем на языке высокого уровня
Сможете доказать? ;) Вот Вам и тема для очередной Хабр-статьи: возьмите какую ни будь задачку из общеизвестных (игра Жизнь, задача коммивояжера и т.д.), решите на языке высокого уровня, а потом ускорьте критические участки, переписав их на ассемблере. В статье сравните время выполнения и поделитесь секретами успеха, приложите исходный код. Уверен, что такая статья многих здесь заинтересует.
Да. Стандарты ограничивают и дисциплинируют. Прежде всего, производителей компиляторов и других инструментов программирования. Благодаря стандартам к «болту» одного производителя всегда можно подобрать «гайку» другого. От любого из существующих стандартов можно отказаться и оформить тот же текст в виде рекомендаций, но если среднего школьника, которому положено посещать уроки информатики и который не собирается стать профессиональным программистом, заставить вызубрить эти рекомендации – такая задача будет ему не по силам. А стандарты школьникам зубрить не нужно: компилятор обругает в том месте, где ученик отошел от стандарта. Думаю, что в школе и на первых курсах института самомодифицирующийся код изучать не надо: пусть сначала плавать научатся. И я любил работать на ассемблере: вплоть до Intel 80486 включительно удавалось творить чудеса (особенно для NP задач), а потом возросшие ресурсы позволили реализовать мощные оптимизаторы – я (и мои знакомые и сослуживцы по ассемблерным делам) быстро обнаружили, что из написанного на языке высокого уровня кода получается гораздо более быстрый «экзешник», чем нам удается сделать на ассемблере.
Turbo Pascal с первых версий ради удобств сильно отходил от стандартов. Поэтому, например, в США многие преподаватели считали его не учебным. Интерпретатор нашего бота не позволяет написать «goto labels[index]^», выдавая две синтаксических ошибки: «integer expected» и «illegal symbol».
Первоначально одной из основных целей Паскаля была «учебный язык», т.е. язык для обучения программированию. Поэтому даже неискушенному новичку на Паскале написать очень плохой код гораздо труднее, чем на других языках :) Си, например, тоже довольно простой язык (если сравнивать с С++), но он очень гибкий. Опытные кодеры считают эту гибкость достоинством, но новичкам она вредит: такого понаписать можно… Описание Паскаля занимает всего 30 страниц — по силам прочитать и понять любому фанату КР, даже если никогда до этого не программировал и в школе информатику не учил :) И на форумах фрагменты кода на Паскале обсуждать удобно — никто не говорит, что не понимает столь простого языка :))
Согласен, что скриптовые языки зачастую узко специализированы, но у нас другой случай: мы использовали язык общего назначения (Паскаль) в качестве скриптового :)
Согласен, что Паскаль развивается. В том числе и в виде Дельфи (есть еще и Free Pascal и др.). До Delphi-7 (включительно) развитие шло органично: делались пристройки, но сохранялось основное очень простое ядро. Отсюда была хорошая совместимость со старыми версиями. А потом стало несовместимым, и многие из тех, у кого много старого кода, продолжают использовать Delphi-7. Пример: игра КР (для которой упомянутый бот).
Простые языки подходят для решения очень многих задач. Не для рекламы, а только в качестве примера упомяну наш проект игрового бота. Там, на мой взгляд, совершенно обосновано в качестве языка скриптов взят стандартный Паскаль. А взяли бы мы что-то посложней (или что-то попроще — совсем примитивное), до сих пор бы на старте буксовали :)
Как законопослушный гражданин может застраховаться от судебной ошибки? Ни одна система, ни один антивирусник не дают 100%-ную гарантию от троянов. Вполне может сесть троян, который пошлет какое-нибудь нехорошее сообщение, пока я пишу этот текст. Или же быть уже посажен в бесплатно распространяемую программу или ОС. Например, найдется какая-нибудь очень удобная сборка Линукса, загружу live DVD, а что там троян, можно и не обнаружить. Как в других странах решается эта проблема?
Зачем делают языки — хороший вопрос. Могу предположить несколько не очевидных вариантов.В Вики есть статья «Эзотерический язык программирования» — «в качестве шутки». В большинстве универов мира препод должен заниматься научной работой. Создать язык для отчетов подойдет :) BTW были утверждения, что Си был создан в качестве шутки :)
Вики утверждает, что сейчас более восьми тысяч языков программирования и их число растет. Т.о. вероятность новому языку стать популярным уменьшается. Если не произойдет никаких революций, то языки скоро перестанут изобретать. М.б. это и к лучшему ;)
Чем сложнее язык — тем больше багов окажется в его реализации, тем сложнее организовать достаточно полное тестирование. Но дело не только в разработчиках/кодерах языка и в его тестерах, но и в переносимости на другие платформы, в том числе, появившиеся уже после реализации языка. Кроме того, возрастает сложность стандартизации. Сложность изучения будет тормозить распространение языка. Это студентам хорошо, когда, помимо других предметов, на изучение какого-нибудь языка отводится целый семестр с лекциями и семинарами. Если студент не тупой лентяй, то может не торопясь вникать и разбираться. А работающему в коммерческой компании программисту обычно отводят очень сжатые сроки на изучение. И изучать он постарается не весь язык, а только то, что нужно для конкретной работы. Для больших проектов, чем сложнее и гибче язык, тем сложнее руководителю проекта установить правила написания и документирования кода. Чаще будут возникать ситуации, когда один кодер жалуется на другого, что тот пишет слишком трудно читаемый и трудно модифицируемый код. BTW C/C++ за это критиковали. В.Ш.Кауфман в одной из статей утверждает, что как бы ни старались разработчики языка и его стандартизаторы, любой язык будут содержать неоднозначности («темные места»). Количество этих неоднозначностей — один из основных параметров оценки качества языка. Исходя из общих соображений: чем сложнее язык и чем он гибче, тем больше будет неоднозначностей — ниже качество.
Что касается умножения матриц — они нужны не только в числодробилках. Например, в теории графов куча нечисленных задач с очень широким кругом приложений: от химии до интернет-технологий. Многие из этих задач решаются в том числе и матричным подходом.
Может революций и не будет. Тогда софт еще больше отстанет от железа :(
Ceylon не знаю. Вики утверждает, что он со строгой статической типизацией. Это не попытка наступить второй раз на грабли Виртовского Паскаля, где была невозможна универсальная функция умножения двух матриц? ;)
Спасибо. Нужно будет присмотреться внимательнее к этому языку. Хотя про исправление косяков у меня очень пессимистичные впечатления. Если в целом взглянуть на последние десятилетия — то прогресс в языках тормознул: случилась в прошлом веке так называемая ОО-революция (ей предшествовали структурная и модульная революции) и больше никаких революций. Хоть и японцы 5-ое поколение обещали, другие высказывали мнения, что макросы электронных таблиц — качественно новый уровень языков программирования. Тот же Eiffel контракты предложил. Были еще всякие манифесты новых парадигм, только пока никаких революционных сдвигов, сравнимых с ООП, они не произвели.
полученная эмпирически. Эта формула — 4х этажная дробь, где много всяких буковок и коэффициентиков. Студенты должны были ее знать, чтобы сдать экзамен на ХФ МГУ :) А в физмат школе, где я учился, мы должны были помнить формулу синуса тройного угла и еще кучу подобного мусора, который можно посмотреть в любом справочнике.
А Жизнь можно таким образом в 2-3 раза ускорить? На мой взгляд, это неочевидно. М.б. на 10-20% — более реалистичное ожидание?
Ok.
Наверное есть. Это можно предположить, исходя из общих соображений. Вопрос в том, велика ли доля таких задач? Может, это частные случаи, какие-то редкие мелочи, неучтенные при создании компилятора? Если вспомнить компиляторы для IBM 360/370, то там почти со 100%-ой гарантией перенос на ассемблер критического участка кода давал заметный выигрыш. Сейчас, благодаря прогрессу, не всегда очевидно, стоит ли игра свеч, т.е. время на перенос можно потратить много, а выигрыш может оказаться очень небольшим.
На столь общее утверждение существует столь же общее возражение: некоторые люди иногда совершают странные и непонятные стороннему наблюдателю поступки ;) М.б., со времен IBM 360 сложилась традиция какие-то специальные функции на ассемблере писать? ;) Переносили старый код и, недолго думая, все, что на ассемблере, написали на ассемблере. (Я, конечно, несколько утрирую, но в столь общих рассуждениях это неизбежно :)
Согласен. Но традиционно, даже в лучших универах, математику и естественные науки изучают путем зубрежки формул, теорем, доказательств и т.д. (А студенты-историки даты зубрят :))
А если ученик возьмет совсем экзотический язык, который мало кто знает? Нпр., в моей коллекции есть описания и трансляторы языков T и Dee. Слышали о таких? ;)
Сможете доказать? ;) Вот Вам и тема для очередной Хабр-статьи: возьмите какую ни будь задачку из общеизвестных (игра Жизнь, задача коммивояжера и т.д.), решите на языке высокого уровня, а потом ускорьте критические участки, переписав их на ассемблере. В статье сравните время выполнения и поделитесь секретами успеха, приложите исходный код. Уверен, что такая статья многих здесь заинтересует.
Согласен, что Паскаль развивается. В том числе и в виде Дельфи (есть еще и Free Pascal и др.). До Delphi-7 (включительно) развитие шло органично: делались пристройки, но сохранялось основное очень простое ядро. Отсюда была хорошая совместимость со старыми версиями. А потом стало несовместимым, и многие из тех, у кого много старого кода, продолжают использовать Delphi-7. Пример: игра КР (для которой упомянутый бот).
Что касается умножения матриц — они нужны не только в числодробилках. Например, в теории графов куча нечисленных задач с очень широким кругом приложений: от химии до интернет-технологий. Многие из этих задач решаются в том числе и матричным подходом.
Ceylon не знаю. Вики утверждает, что он со строгой статической типизацией. Это не попытка наступить второй раз на грабли Виртовского Паскаля, где была невозможна универсальная функция умножения двух матриц? ;)