|
Цитата: |
|
|
|
|
|
|
|
|
|
• Assembler......Писать на нём практически так же сложно как и в машинных кодах только теперь использовались не цифры а понятные слова.
|
|
|
|
|
|
на современных макоассемблерах пишется ничуть не сложнее, чем на языках высокого уровня
|
Цитата: |
|
|
|
|
|
|
|
|
|
Вот и весь спор (Скорость разработки vs скорость кода)?***
В общем Borland пока рулит можно выбирать любой компилятор и вперед. Мой выбор Delphi))•
Подведём итог:
1. Если вы будете писать базы данных, программы общего значения или утилиты то ваш язык Delphi или C++
2. Если это игры, то желательно Visual C++ или Watcome C плюс знание Assembler,
но это не значит что нельзя использовать Delphi или C++ Builder.
3. Если драйверы и работа с "железом" где критичен размер фаила то ваш язык чистый С или Assembler.
|
|
|
|
|
|
все-же я критерии выбора языка программирования немного изменил-бы. И самым первым критерием поставил бы вопрос "для какой платформы". Поскольку некоторые платформы подразумевают ограниченный выбор лишь из: маш.коды, ассемблер, С, Fort или вообще без выбора - только что-то одно из перечисленных (или не перечисленных). Вторым критерием я бы поставил вопрос переносимости между платформами, что может еще более сильно сузить выбор инструмента. Третьим критерием является предметная область, поскольку для решения некоторых специфичных задач уже давно выбраны соответствующие эффективные пути решения. Ведь было бы странно писать на Дельфях приблуду, собирающую отчет из 1С, или рисовать в билдере прогу отображения странички сайта (хотя нет ничего невозможного
). После чего я бы поставил условие коллективной разработки, поскольку некоторые инструментальные средства интегрируют в себя средства поддержания коллективной разработки проекта, в некоторых инструментальных средствах этот вопрос можно решить организационно, а в некоторых средах (Акцесс, кларион и т.п.) этот вопрос не решается принципиально. И лишь теперь бы обратился к вопросу "скорость выполнения (потребляемые программой ресурсы) vs скорость написания (потребляемые разработчиками ресурсы)". И рассматривая этот аспект, я бы увидел, что скорость написания не всегда равна удобству сопровождения (а зачастую между ними обратная зависимость). Кроме того, нельзя упускать из виду и квалификацию персонала, сопровождающего проект. Очевидно, что если проект ориентирован на сопровождение исключительно силами заказчика, как правило имеющего в штате лишь операторов и в лучшем случае еще и админа, то проект должен предусматривать гибкие настройки без внесения изменений в программный код, что увеличивает как сроки разработки проекта, так и его стоимость. С другой стороны, если заказчик имеет в штате какого-нибудь программиста, работающего с определенным набором инструментов, то очень часто заказчик будет стремиться ограничить выбор инструментария именно этим набором. Так-же нельзя забывать и о таком неочевидном факте, что иногда скорость (не путать с удобством) разработки на языке ООП или в визуальной среде оказывается ниже, чем на классическом процедурно-ориентированном языке высокого уровня.
подведу краткий итог: все языки хороши. каждый - в своем, сугубо индивидуальном случае. Если вы довольны своим выбором, значит вы угадали, если недовольны - неугадали
. А поскольку все языки достаточно сходны между собой, то имеет смысл выучить лишь один язык (или по одному языку низкого, среднего и высокого уровня, ООП и визуального программирования) и переход на другой язык (при наличии соответствующего справочника команд, функций, объектов) будет практически безболезненным и мгновенным.
Желаю вам получать от программирования моральное и материальное удовлетворение!