есть ли они? пока видны проблемы только... На чём програмируют в Linux'сах? и в висте... Может действительно - перейти на фасм? не нравится мне его стиль... А с виндой что будет, сколько она ещё протянет...? может были попытки портирования масма на висту ? в принципе какая разница XP - есть недостатки, но система ещё долго будет устраивать всех, кроме самих мелкософтовцев. Предлагаю провести акцию протеста против ликвидации ХР, которую планируют - во всех сообщениях, везде, в конце предложений добавлять "хрю", например : "Привет, хрю. Хочу написать свою ось, хрю. Подскажите в какую сторону копать, хрю." в таком вот аспекте...
driver что то ты какойто бред написал. Говоришь про ассемблер и его перспективы и .. >> На чём програмируют в Linux'сах? и в висте... Может действительно - перейти на фасм? не нравится мне его стиль... А фасм это не ассемблер? а в Висте программируют и на масме и на фасме >> А с виндой что будет, сколько она ещё протянет...? А что с ней может быть? >> может были попытки портирования масма на висту ? в принципе какая разница MASM 8.0 , не тот что пакет http://www.masm32.com/ а именно версия файла 8.0, он поддерживает x64
плюс масма это поддержка библиотек sdk и ddk, + к тому IDA выдаёт листинги в синтексисе масма, и масм поддерживает отладочную информацию в отличии от фасм. Ну а фасм в свою очередь низкоуровневый тем и крутой, всякие вирусы на нём писать самое то.
Те, кому нравятся и на ZX Spectrum прогрммируют и перспективы тут вообще побоку. А если ты имеешь ввиду рынок программистов под x86-64 hardware, то здесь ассемблер сегодня это просто набор вспомогательных знаний, который может быть желателен, но необязателен. Для сравнеия, тебя вряд ли возьмут работать водителем, если ты знаешь устройство ДВС, но не умеешь водить. Вот и весь расклад. Как таковой вакансии "программист на ассемблере под x86-64" за последние пару лет я не встречал.
всё можно сделать и на ассемблере, и оно будет лучше согласен... сделал текстовый редактор, открывает 1 метр за 0.1 сек, и это долго потомучто ищет закладку... надо бы переделать немножко. Даже штатные программы винды - дохлые какие-то... проблема - в стандартизации функций и макросов масма ... раздолбайство полное в этом отношении...хрю
Давай, сделай ERP с CRM и BPM, с поддержкой нескольких СУБД на базе распределённых транзакций. И чтобы RIA была ессно, а для удобства придумай аналог ORM для ассемблера и его прикрути, нам ведь ещё масштабируемость нужна. LOL
Програмирование будущего будет с голосовым управлением, просто говоришь masm256v17 - "Сделай-ка ERP c CRM & BPM" кстати, а что за звери эти..., как их - ЕРП и... хрю
Да так, люди сами себе жизнь усложняют, придумывают что-то... Не чтобы текстовые редакторы писать и файлики туда грузить
Помню на одном форуме человек очень забавно объяснил на таком примере: Более точную формулировку можно в вики глянуть.
... ничего сложно в этом нет, группа товарсчей, запасшись солидным запасом пива, сделает всё это и на асме, сложно будет потом остальным разобраться с протоколами и ....что и наблюдается. фирмы-производители программных продуктов умышленно усложняют, искажают и скрывают достоверную информацию всеми возможными способами...хрю
2FED, главное -- это сложность. Даже дай тебе неограниченные временные и технические ресурсы, ты будешь не в состоянии реализовать нечто подобное, т.к. это очень сложно. Не потому, что ты плохо знаешь ассемблер, 50 команд выучить легко, а просто потому, что человеческие способности ограничены. Поэтому программисты и стараются как можно сильнее абстроагироваться от деталей, которые не имеют отношения к решаемой задаче. Именно желаемый уровень абстракции позволяет реализовывать сложные приложения за приемлемое время и цену. Но главное, что сложность этих систем для разработчиков такова, что они могут эффективно дорабатывать и расширять ПО, при необходимости быстро исправлять ошибки. ERP системы стоят огромных денег и обеспечивают работой кучу людей, а чего стоит текстовый редактор, который грузит 1 мб за 0.1 секунды?
Подозреваю дело исключительно в наличии большого числа наработок в других ЯП, которых нет в асме. В ЯВУ, есть сравнительно небольшое число встроенных функций, и функций библиотек, комбинируя которые можно быстро написать программу. Кроме того, за самими операторами языка скрывается немало кода, например автоматический сбор мусора и т.п.. Все это позволяет свести программу к нескольким сотням операторов. Та же программа на асме будет занимать тысячи операторов если не больше. В то же время, если бы были схожие средства для асма, можно было бы приблизить сложность программы на асме к программе на ЯВУ, но ненамного, т.к. синтаксис асма не столь лаконичен. Вообще-то говоря, возможно эта проблема не имеет решения. Используя большое количество кода в виде "черных ящиков", мы проигрываем в оптимальности кода, т.к. эти ящики слишком универсальные и потому слишком большие. Используя менее универсальные операторы и подпрограммы, мы получаем код большего размера.
W4FhLF Не будем спорить, пускай каждый останется при своём мнении, я один конечнобы этого всего не сделал, но как сказал товарисщ driver группа товарищей смогут это сделать. Просто для одного человека это будет слишком долго и он не успеет за технологиями, когда он закончит оно уже будет не актуально и будет требоватся что то новое. ps driver хватит хрюкать, вы же не свинка )