0
Вопрос: требуется ли современному программисту знанание ассемблера?
| 1. разумеется | 23 | (50%) | |
| 2. общих сведений вполне хватит | 16 | (34.78%) | |
| 3. не требуется | 6 | (13.04%) | |
| 4. что такое ассемблер? | 1 | (2.17%) | |
| Всего: | 46 | ||
-
-
18.01.2005 в 00:27-
-
18.01.2005 в 00:56-
-
18.01.2005 в 01:11Согласна на 200%. Причём, хватает даже уровня 8086. Ничего суперэфективного на этом не напишешь, но по крайней мере понимаешь как оно работает и начинаешь бережнее относиться к памяти и процессорному времени.
-
-
18.01.2005 в 01:39-
-
18.01.2005 в 01:42иными словами, задача программиста - бездумно закручивать гайки стоя на конвеере?
программист - это и есть создатель экскаватора
-
-
18.01.2005 в 10:52-
-
18.01.2005 в 14:06обсуждение экскаваторов и зданий - пустая демагогия. для начала, ты сам ассемблер знаешь хотя бы на уровне написания перемножения матриц?
-
-
18.01.2005 в 14:23-
-
18.01.2005 в 14:48что ж, боюсь, мы общаемся немного на разных языках.
Потому что ни разу не понадобилось
в высокоуровневом программировании, ассемблер в явном виде может никогда не стать критически необходимым. ты всего-лишь не будешь знать, что одну и ту же задачу можно решить разными способами с, соответственно, разной эффективностью. причем, как я уже писал, не обязательно самому переписывать высокоуровневый код на ассемблерный или чесать левой ногой за правым ухом. знание ассемблера помогает изначально более оптимально проектировать и реализовывать алгоритм, ускоряет отладку (особенно, в неитнтерпретируемых языках).
-
-
18.01.2005 в 15:29-
-
18.01.2005 в 16:01Да, но вопрос стоит "требуется ли", а не "может ли пригодиться"
согласен. если предполагать, что если программа "абы как" работает, то это хорошая программа.
вопрос "требуется ли современному программисту знанание ассемблера", в первую очередь, предполагает разработку качественного программного обеспечения, что, в свою очередь, приводит к оценке эффективности работы приложения. в свете этого, могу сказть, что знание ассемблера и, как следствие, низкоуровневой архитектуры компьютера, в большинстве задач позволяет точнее определять системные требования на этапе постановки тз, выбирать средства разработки, осущствлять эффективное проектирование и оптимальную реализацию программного продукта.
боюсь, мои слова покажутся слишком категоричными, но я считаю что, программист, знающий ассемблер, реализует задачу априорно не менее эффективно, а, в подавляющем большинстве случаев, оптимальнее, нежели программист, условно эквивалентный первому, но ассемблер не знающий.
-
-
18.01.2005 в 18:22Во-вторых, качество программного обеспечения зависит не только от скорости. Порой на целую комманду хватает одного человека, который что-то определённое умеет, а иногда и он не нужен, если можно воспользоваться чем-то уже существующим.
Учитывая, что ассемблер намного старше всего, чем сейчас пользуется большинство программистов, можно предположить, что определённые принципы (в связи с опытом, полученным от ассемблера) уже разработаны и используются без знания самого ассемблера.
-
-
18.01.2005 в 18:59программист, не тративший время на изучение ассемблера, потратил его на изучение чего-то другого, в результате чего программирует быстрее, эффективнее
совсем не обязательно скорость программирования, а уж тем более эффективность, будут выше. скорость, имхо, определяется не только теоретическими знаниями, но, главным образом, умственными возможностями конкретного человека и его опытом. практика программирования на ассемблере во многом помогает в программировании и на более высокоуровневых языках (обратное, стоит заметить, тоже верно).
качество программного обеспечения зависит не только от скорости
это и не утверждалось - был выдвинут постулат о том, что два одинковых по функциональным возможностям приложения будут с большой вероятностью довольно сильно отличаться в случае, если одно из них создавалось людьми знающими ассемблер, а другое - нет. иными словами, одну и ту же задачу можно решить различными способами. из множества вариантов решений человек знающий ассемблер с гораздо большей вероятность выберет наиболее эффективный.
ассемблер намного старше всего, чем сейчас пользуется большинство программистов, можно предположить, что определённые принципы уже разработаны и используются без знания самого ассемблера
возникает ощущение, что ты просто не понимаешь, что такое ассемблер.
-
-
18.01.2005 в 22:35Нельзя сравнивать 2 человека с единственной разницей - знанием ассемблера. Потому что, если один его не знает, то он знает что-то другое, или просто опытней в своей сфере.
Однозначно программист с 5ю годами Джавы и 5ю годами С++ будет лучше, чем просто программист с 5ю годами Джавы. Но если сравнить их с третим, у которого практика в Джаве 10 лет, то первый два уже проигрывают.
Опять же, вопрос стоит требуется ли знание или нет. Я считаю, что определённо не требуется. Может помочь, пригодиться, улучшить работ и так далее - я не отрицаю, но тем не менее не требуется, оно далеко не обязательно.
-
-
18.01.2005 в 22:47А я бы из троих выбрала в качестве спеца как раз второго. Он имеет достаточный опыт в основном языке, но у него в запасе есть ещё один, а значит, дополнительные подходы, больше понимания в том, как оно устроено изнутри. Скажем, программер пишущий только на Java нечасто задумывается о количестве выделенной памяти и сроках её освобождения.
Пойми, работая только на одном языке и, что бывает чаще всего, над однотипными задачами, очень быстро достигаешь потолка, взгляд замыливается и все функции выходят как из-под штампа (да часто так и бывает - лень-матушка под ручку с Copy-Paste). Ну и чего ж в этом хорошего?
-
-
18.01.2005 в 22:54Однозначно программист с 5ю годами Джавы и 5ю годами С++ будет лучше, чем просто программист с 5ю годами Джавы. Но если сравнить их с третим, у которого практика в Джаве 10 лет, то первый два уже проигрывают.
не совсем корректный пример. ассемблер - это основа для любого высокоуровневого языка, в связи с чем сравинть его можно было бы разве что с машинными кодами (хотя, по существу, это одно и то же). к тому же, на изучение ассемблера не потребуется большое количество времени, которое может быть скомпенсированно более быстрым усвоением нового материала, относящегося к языкам высокого уровня. об увеличении скорости программирования и отладки я уже писал.
Может помочь, пригодиться, улучшить работу и так далее - я не отрицаю, но тем не менее не требуется, оно далеко не обязательно.
если я тебя правильно понял, то хочешь сказать, что относишься к тем людям, которые даже не стремятся выполнять работу качественно? если для тебя руководствующим является принцип "программа работает ну и ладно", то, думаю, эту дискуссию имеет смысл завершить
-
-
18.01.2005 в 22:56Ты бы выбрала второго, раз опыт достаточный в основм языке? Тогда что если у тебя на выбор человек работающий в джаве 2 года (а не 10) и человек работающий год на джаве и год на с++? Всё равно последнего?
-
-
18.01.2005 в 23:11В первую очередь надо смотреть не на количество лет опыта, а на умение мыслить не догмами и быстро учиться чему-то новому. Согласись, что знание нескольких языков в этом плане дают массу преимуществ.
-
-
18.01.2005 в 23:24offtopic: Джава вообще-то достаточно разнообразна, чтобы была определённая свобода эксперементировать. я бы так не сказал. эту дискуссию лучше вынести в отдельную тему.
человек зацикливающийся на одном средстве разработки проигрывает уже из-за отсутствия кругозора - ему не с чем сравнивать используемые им средства.
Караидель
полностью согласен
-
-
18.01.2005 в 23:28Совершенству нет предела. Выполнить во время и качественно часто лучше, чем выполнить экстра-качественно, но затратить на это в два раза больше времени. "Программа работает, ну и ладно" в некоторых случаях на самом деле является критерием. Иногда не важно, проходит у тебя ночью импорт за пол часа или за минуту. Иногда не важно, проходят ли определённые вычисления за тысячную секунды или 50, когда окно будет вырисовываться дольше.
Причём оптимизации можно достичь, сменив библиотеку на более лучшую. Если всё написано правильно с точки зрения объектового программирования, то такая смена будет предельно проста - проще, чем отлаживать существующее. (Называется пусть оптимизацией занимаются создатели этих библиотек).
Караидель, возможно, но знание нескольких языков не говорит, что среди них *обязательно* должен быть ассемблер, а речь как раз об этом.
-
-
18.01.2005 в 23:37-
-
18.01.2005 в 23:49Таки говорит. Потому как знание ассемблера обычно тесно связано со знанием архитектуры процессора, соттвественно с пониманием как написанный код работает. Что даёт огромное преимущество в написании красивого, быстрого и компактного кода.
Иначе программисты начинают напоминать двух медсестёр из анекдота несущих одну клизму: одна знает как ставить, а другая - куда.
-
-
19.01.2005 в 00:27он может сравнивать пассивно - читать, что по этому поводу думают другие
бред. если так рассуждать, то учиться вообще не нужно - достаточно запомнить два-три правила и тупо встать за конвеер. все в жизни досконально изучить, разумеется, не получится, но понять ядро, лежащее в основе всех языков программирования, думаю, нужно.
он может сравнивать, но ему не обязательно наращивать многолетний опыт, чтобы сравнить два языка и выбрать, какой больше нравится
в очередной раз спрашиваю: кто-нибудь что-нибудь говорил о многолетнем опыте изучения того же ассемблера? изучи хотя бы основы и поймешь, нужно ли тебе разбираться в нем дальше или нет
сравнивают два подобных языка, а не ассемблер и джаву
прочитай еще раз текущую тему форума
-
-
19.01.2005 в 00:52почему "нижней границей" должен быть именно ассемблер? Почему не сам машинный код?
не пойму, кто тебя останавливает?
Выполнить вовремя и качественно часто лучше, чем выполнить экстра-качественно, но затратить на это в два раза больше времени
читай внимательно предыдущие посты.
"Программа работает, ну и ладно" в некоторых случаях на самом деле является критерием.
если занимаешься только такими программами, повторно предлагаю завершить дискуссию
Иногда не важно, проходят ли определённые вычисления за тысячную секунды или 50, когда окно будет вырисовываться дольше.
имхо, бессмысленное утрирование, особенно, со стороны java-разработчика
в более сложных системах речь идет не о миллисекундах
Причём оптимизации можно достичь, сменив библиотеку на более лучшую.
собираешься провести несколько десятков лет в поисках нужной тебе библиотеки в специфической области?
Если всё написано правильно с точки зрения объектового программирования, то такая смена будет предельно проста - проще, чем отлаживать существующее
объектное программирование здесь вообще не при чем. во-первых, смена библиотеки в говорит об ошибочном выборе на стадии проектирования. во-вторых, ООП не обязывает используемые внешние библиотеки совпадать не только по методам, но и по принципу работы. время на итеративные поиск новой библиотеки и переход на нее могу в несколько раз превысить время основной разработки. необоснованное же использование оберточных классов так же повышает объем бесполезно потерянного времени.
Называется пусть оптимизацией занимаются создатели этих библиотек
в твоем понимании, программирование - это взять полностью готовую библиотеку и вызвать пару ее методов?
-
-
19.01.2005 в 01:39Выбор мог быть ошибочным. Ошибки случаются. Плюс, нужной библиотеки могло просто не быть, о ней могли не знать вообще (а не сравнить и выбрать не ту) и так далее.
В моём понимании, библиотеки часто занимаются более-менее трудоёмкими вещами. А если не занимаются, то часто можно найти библиотеку, которая занимается. Так как такие библиотеки написаны намного более продуманно, то использовать библиотеку часто бывает более выгодно, да и самому писать - изобретать существующий велосипед.
Я все посты читал поностью и достаточно внимательно.
"повторно предлагаю завершить дискуссию"
Я вообще тебя не заставляю эту дискуссию вести... да и заставить не в моих силах в люом случае.
"не пойму, кто тебя останавливает?"
Был приведён пример в ту и другую сторону. Вот и спрашивается, откуда взялась именно эта граница? А если она откуда-то и взялась, то она абсолютна или относительна? Собирается ли она двигаться с развитием? Не должна ли она уже была сдвинуться?
"бред. если так рассуждать, то учиться вообще не нужно"
Я не говорил, что должен, я говорил что может. Такая возможность действительно существует. Ты собираешься попробовать все языки программирования, которые существуют в мире? Или ты прочитаешь про какой-нибудь, что он бесполезен, и не будешь его даже пробовать? Люди не просто так деляться опытом и называть это бредом, думаю, не стоит.
"в очередной раз спрашиваю: кто-нибудь что-нибудь говорил о"
В данном случае речь не шла о ассемблере, а о сравнении языков. Подобных языков.
"прочитай еще раз текущую тему форума"
Я о том же, как раз.
-
-
19.01.2005 в 02:22библиотеки часто занимаются более-менее трудоёмкими вещами. А если не занимаются, то часто можно найти библиотеку, которая занимается
поверь моему опыту, библиотеки существую далеко не для всех областей. к тому же следует споставлять стоимость библиотеки с планируемой прибылью от реализации разрабатываемого программного продукта.
Так как такие библиотеки написаны намного более продуманно, то использовать библиотеку часто бывает более выгодно, да и самому писать - изобретать существующий велосипед
ты никогда не задумывался, что эти библиотки возникли не сами собой. их тоже написали. причем люди.
в твоем понимании, программирование - это взять полностью готовую библиотеку и вызвать пару ее методов?
Был приведён пример в ту и другую сторону. Вот и спрашивается, откуда взялась именно эта граница?
это не граница - это основа, на которой строятся все высокоуровневые языки. зная основу, ты уже априорно знаешь принцип работы тех средств разработки, которыми ты пользуешься. от глубины понимания принципов зависит оптимальность их использования.
очередной высокоуровневый язык в конечном истоге компилируется в машинный код (или код виртуальной машины) либо интерпретируется "на лету", что не принципиально. важно другое - какой бы язык ты ни взял, он неизбежно приведет к ассемблеру.
Ты собираешься попробовать все языки программирования, которые существуют в мире?
отвечаю своей же цитатой: все в жизни досконально изучить, разумеется, не получится, но понять ядро, лежащее в основе всех языков программирования, думаю, нужно
-
-
19.01.2005 в 02:34Библиотеки кто-то написал. Этот кто-то мог иметь знания ассемблера. Но это не значит, что эти знания *мне* требуются.
"в твоем понимании, программирование - это взять полностью готовую библиотеку и вызвать пару ее методов?"
Да, написание программы состоит из тыкания клавишь на клавиатуре...
"все в жизни досконально изучить, разумеется, не получится, но понять ядро, лежащее в основе всех языков программирования, думаю, нужно"
Отвечаю своим первым комментом:
Зачем?
-
-
19.01.2005 в 02:48ассемблер приведёт к машинному коду... тогда почему не стоит вопрос "требуется ли знание машинного кода"?
рад, что ты спросил. концептуальной разницы между ассемблером и конечным машинным кодом нет - компиляция ассемблерных инструкий в машинные инструкции крайне тривиальна, чего нельзя сказать о компилировании высокоуровневого языка.
в твоем понимании, программирование - это взять полностью готовую библиотеку и вызвать пару ее методов? - Да, написание программы состоит из тыкания клавишь на клавиатуре...
имхо, этим занимаются кодеры, а не программисты.
Отвечаю своим первым комментом: Зачем?
см. предыдущие посты
-
-
19.01.2005 в 03:18Я сказал *написание*...
см. предыдущие посты
Нетушки, это ты начинаешь зацикливать дискуссию, а не я.
-
-
19.01.2005 в 08:14Да, написание программы состоит из тыкания клавишь на клавиатуре...
Непосредственно на тыканье клавиш уходит всего 30% времени создания программного продукта. Остальное: планирование и отладка. Причём, идеальной считается ситуация, когда время планирования равно минимум 50%.
Отвечаю своим первым комментом:
Зачем?
Иначе программер уподобляется хирургу не знающему анатомии.