Языки программирования
Дело в том,что я изучил ассемблёр и решил сравнить код на ассемблёре и другие,и вот что уменя получилось:
(Вывод строки Hello,world!)
FASM-->
ORG 100h
push cs
pop ds
mov ah,9
mov dx,text
int 21h
int 20h
text db 'Hello,world!$'
<--
Размер:24 байта
Asic-->
Print "Hello,world!"
<--
Размер:360 байт
C++(Tubo 3.5)-->
#include <stdio.h>
main(){
printf("Hello,world!");
return 0;
}
<--
Размер:(ужас)8,47 kb!
Delphi(7.0,console)-->
program Project2;
{$APPTYPE CONSOLE}
uses
SysUtils;
begin
Write('Hello,world!');
end.
<--
Размер:(это вообще)40kb
Может эти размеры не так и ужасны,но посмотрите какой отрыв между ассемблёром и языками высого уровня,и это я ещё не программу написал,как говорится чем дальше-тем похлеще...
Я считаю,что вообще нельзя использовать языки высокого прогр.,это же полный атас!
Например:Я написал прогу для чтения тестов,на Делфи она у меня заняла 1,2 мег,а потом на асме:120 кб(от размера сообственно и скорость!)...Мда ,большая разница..
Что уже говорить о таких как:Word,Excel,Photoshop и т.д
В принципе ничего страшного нет,но если подумать-это же деградация!
Вот были времена ДОСа,когда большинство прог писали на АСМЕ-там и скорость и размер,а щас?
Все программисты(не буду уж так резко)обленились
писать на АСМЕ,все пишут на Делфи и т.д
Я считаю что АСМ самый лучший(и сложный)...
Кто думает так или иначе?
Да!
потому, что там опция -On есть
:D :D :D :D :D
Ещё лучше на нём(асме) - писать:D. Асм как таковой не позволяет абстрагироваться от архитектуры, что происходит когда пишешь на каком-нибудь ЯВУ.
Мне иногда люди, пишущие на C++(как они говорят),VB задают бл@ такие вопросы, что просто диву даёшься. А всё потому что они не считают должным изучить АСМ. Поэтому у них в головах порой такая неясность.
Ну а если писать на ЯВУ, то только на чистом C с некоторыми элементами C++(без всяких там MFC,OWL).
Ассемблер и архитектуру проца под который пишешь знать просто необходимо.
Особенно, если пишешь на Java или C#... :)
Ещё лучше на нём(асме) - писать:D. Асм как таковой не позволяет абстрагироваться от архитектуры, что происходит когда пишешь на каком-нибудь ЯВУ.
Чем лучше то? Для чего лучше?
Абстрагирование это лохо?
Тогда вообще не понятно для чего ЯВУ развивают?
А... понял... исключительно для ламеров!
Мне иногда люди, пишущие на C++(как они говорят),VB задают бл@ такие вопросы, что просто диву даёшься. А всё потому что они не считают должным изучить АСМ. Поэтому у них в головах порой такая неясность.
Я вот читаю эту ветку и думаю про то, что порой творится в головах людей, которые, как они говорят, пишут на АСМ...
Ну а если писать на ЯВУ, то только на чистом C с некоторыми элементами C++(без всяких там MFC,OWL).
:D
Во-первых, С - это не ЯВУ.
Во-вторых, "с некоторыми элементамиС++" - это значит писать невразумительные гибриды двух языков? Это зло!
В-третьих, MFC и OWL это не "элементы" С++, С++ к ним вообще не имеет никакого отношения, как к примеру не имеет никакого отношения немецкий язык к зверствам Гитлера.
В-четвертых, ты предлагаешь вообще не использовать никакие библиотеки? Т.е. сознательно не писать ничего сложнее "Hello world" ?
Из всего этого можно сделать вывод, что ты не владеешь ни С, ни С++. Так как же ты можешь авторитетно рекомендовать, либо не рекомендовать изучать эти языки?
Я вот читаю эту ветку и думаю про то, что порой творится в головах людей, которые, как они говорят, пишут на АСМ...
Не без этого!!! :P
Во-первых, С - это не ЯВУ.
Ну дык объясните мне, что есть ЦЭ и с чем его едят.
АссемблЕр(для процов Intel'овского семейства) тоже развивают, к примеру FASM.
ты предлагаешь вообще не использовать никакие библиотеки? Т.е. сознательно не писать ничего сложнее "Hello world" ?
С твоих слов получается, что для тебя нет других библиотек, кроме того же MFC.:o
Ты считаешь, что наличие такой туфты, как MFC - есть благо. Но чем же не устраивает стандартный API? Ведь MFC - это ещё один уровень сверху, а значит новые тормоза!
MFC и OWL это не "элементы" С++, С++ к ним вообще не имеет никакого отношения, как к примеру не имеет никакого отношения немецкий язык к зверствам Гитлера.
Ну конечно, MFC было написано для программеров на Visual Basic'e или АссемблЕре и только они этой библиотекой и пользуются.
Внимательней надо посты читать!!!:devil:
(Аналогия : C++ и немецкий язык, Гитлер и MFC c OWL.:D)
Из всего этого можно сделать вывод, что ты не владеешь ни С, ни С++. Так как же ты можешь авторитетно рекомендовать, либо не рекомендовать изучать эти языки?
А я и не говорил, что владею в полной мере этими языками. Мне кажется, что я в достаточной мере успел с ними познакомиться, чтобы выбрать в качестве основного языка АссемблЕр, который я продолжаю изучать.
По поводу моего предыдущего поста - я просто таким образом выразил своё мнение.
И главное : [color=limegreen]АссемблЕр[/color] - это [color=indigo]дЗен[/color]. :angel:
Уверен? :)
А как на счет ассемблера AT&T ?
xorl %eax,%eax - и чего здесь оптимизировать?
8)
И каково все это писать на ассемблере, имея в распоряжении всего 4 регистра общего назначения и стек! Можно, конечно, использовать для хранения значений переменных ячейки памяти, но тогда теряется реентрабельность.
Ну, если постараться можно использовать и 7(8) регистров : eax,ecx,edx,ebx,esi,edi,ebp,(esp) (а для 64-битного режима IA-32e их целых 16!!!:!!!: ).
А выполнение арифметических операций (не говоря уж о тригонометрии)... очень неудобно пользоваться уродски реализованными инструкциями mul и div.
А для чего тогда нужен FPU со своими 8 регистрами(которые также юзаются MMX). А SSE,SSE2,SSE3, где добавлены 8 128-битных регистра(а в 64-bit IA-32e их 16)???
:-? :-? :-?
В отличие от других языков програмирования-Ассемблёр имеет расширенный доступ к выше переч.(да и не только)
А например в Паскале это есть?(Ну сопроцессор вроде есть)
Вот было бы побольше программ,написаных на Асме,а то по этим Делфиновым апликациям и тому подобному уже хочется матом ругатся...
Ну что ещё сказать,человек всегда выбирает то-что ему легче(теряя производительность)
В конце концов приходит C# и .NET и все ломают головы - "откуда тормоза? куда уходят ресурсы? почему уязвимости?".))
И ещё )) . Если интелу вздумается в проц аппаратную фурье функцыю вляпать (для mp3,mpeg кодеков и т.д.), что тогда ? ))
Просто неплохо бы, если программер(не веб и т.п. - там он нужен как рыбе зонтик) знал ассемблер. Тогда бы он(возможно) набивая код на ЯВУ,осуществлял бессознательную оптимизацию.
Представлял бы всё несколько в ином виде, что несомненно бы дало положительный результат.
А то есть те, кто любят писать криво, не задумываясь как сделать лучше, и полностью полагаются на компилятор .
А компиляторы бывают разные, они являются продуктом работы ЛЮДЕЙ, соответственно они могут содержать ошибки.
А ассемблЕрщик наверняка сможет решить проблему, не дожидаясь релиза нового компилятора(линкЁра).
:P
ГыГы, все, кто пишет что-то покруче хеллоуворд. Кто скажет хоть один серъезный проект написаный на асме?
[color=indigo]RADASM IDE[/color] : [color=crimson]radasm.visualassembler.com[/color]
;)
Зря я сюда ввязался... Весовая категория, действительно, не та...
Так и хочется ляпнуть что-нибудь про XP, TDD, рефакторинг, юнит-тестирование, профилирование, методы оптимизации, ООА&Д и ООП в конце концов. Но боюсь, после фразы " Тогда бы он(возможно) набивая код на ЯВУ,осуществлял бессознательную оптимизацию.", все мои заготовленные аргументы просто тонут в темноте...
Вот ещё "перлы":
"проблема ЯВУ не в обстрагировании от харда ))(каждому языку время и место ), а в постепенном наслоении халявы"
"В отличие от других языков програмирования-Ассемблёр имеет расширенный доступ"
"Но чем же не устраивает стандартный API? Ведь MFC - это ещё один уровень сверху, а значит новые тормоза!"
"Ну что ещё сказать,человек всегда выбирает то-что ему легче(теряя производительность)"
"А компиляторы бывают разные, они являются продуктом работы ЛЮДЕЙ, соответственно они могут содержать ошибки.
А ассемблЕрщик наверняка сможет решить проблему, не дожидаясь релиза нового компилятора(линкЁра)."
"В конце концов приходит C# и .NET и все ломают головы - "откуда тормоза? куда уходят ресурсы? почему уязвимости?".))"
Всего доброго, бодайтесь.
АСМ рулз?
Видно да...
Дай угадать...
АСМ рулз?
Видно да...
Вот почитаю эту ветку, и сразу настроение поднимается :D
АСМ нужен там где он нужен. ИМХО его целесообразно использывать только в части прог, где действительно нужна скорость вычисления. И только в том случае если автор отменно сечет асм и сможет написать код оптимальнее компилятора.
На счет предидущих постов. Если кто и пишет какую глупость, то лучше сказать в чем он ошибается, а не изгалятся над его постом.
Если кто и пишет какую глупость, то лучше сказать в чем он ошибается, а не изгалятся над его постом.
для нормальной дискусии нужно говорить на одном языке. или, как Green сказал, быть в одинаковых весовых категориях. не применительно к квалификации и опыту, а применительно к адекватности и способности мыслить спорящего.
но фразы
Тогда бы он(возможно) набивая код на ЯВУ,осуществлял бессознательную оптимизацию
вызывают сомнения в адекватности оппонента.
РЕБЯТА, ДАВАЙТЕ ЖИТЬ ДРУЖНО!
Глупостей, было действительно ОЧЕНЬ много, поэтому комментировать все просто нет возможности, да и сама аргументация будет, видимо, непонятна (пока).
Думаю, вместо того что-бы спорить, стоит посоветовать почитать про ООП, ООА&Д (для начала про паттерны проектирования), про XP, TDD, рефакторинг, профилирование и оптимизацию.
Скорее всего, после этого опоненты согласятся если не полностью, то частично, что асемблер занимает весьма специфичную и очень узкую область в программировании, и что такой аргумент, как скорость - весьма спорный, а такой аргумент, как оптимальность - отсутствует впринципе.
Доказывать ничего не буду, т.к. это значит прочитать краткий (а может не очень) курс лекций по вышеперечисленным методикам, практикам и подходам.
Вот здесь я приводил несколько ссылок на литературу:
http://forum.codenet.ru/showthread.php?s=&threadid=27210&perpage=25&pagenumber=2
Думаю, вместо того что-бы спорить, стоит посоветовать почитать про ООП, ООА&Д (для начала про паттерны проектирования), про XP, TDD, рефакторинг, профилирование и оптимизацию.
Сейчас появится свободное время и я хотел бы для повышения собственно уровня почитать литературу по этому поводу.
Можете посоветовать конкретные книги (а в идеале ссылку на електронный вариант)?.
Сразу скажу что в гугл я еще не лез. Хотел просто лезть уже с конкретной целью
Сейчас скажу неожиданное даже для самого себя:
РЕБЯТА, ДАВАЙТЕ ЖИТЬ ДРУЖНО!
давайте... а кроме изучения всех тобою перечисленных страшных слов, начинающим кодерам не мешало бы усвоить простую истину: отверткой тоже можно забить гвоздь, но гораздо лучше это сделать молотком. тогда не будет появлятся топиков типа "лучший язык", "лучшая ОС", "блондинки Vs брюнетки" и т. п.
ведь без постановки задачи кричать о преимуществах языка - дурость. я тоже могу сказать, что лучший в мире язык это скрипты на bash+sed+awk. потому что позволяют мне решать рабочие задачи, разрабатывая программы за считанные минуты. и пусть потом ньюбы пытаються следовать моему примеру, пусть пишут движки на bash :D
ЗЫ Матуш,так тебе нужны э-книги по Асму???
Я вообще низнаю что такое баш(баш на баш?)
ЗЫ Матуш,так тебе нужны э-книги по Асму???
bash - Born again shell.
ЗЫ Матуш,так тебе нужны э-книги по Асму???
Ну, вообщето мой пост писался в тот момент, когда Green еще не кинул линк на книги про которые говорил. и я хотел именно эти книги.
По асму тоже не помешает. Кое какая литература у меня по асму есть. Я даже немного ориентируюсь в асме.
На данный момент у меня не возникало потребности использовать асм в моих прогах. Как я уже писал, единственное его применение которое я вижу для себя - это оптимизировать некоторые участки кода. Хотя на данный момент и такой потребности нет.
М-да... ну что сказать...
Зря я сюда ввязался... Весовая категория, действительно, не та...
Так и хочется ляпнуть что-нибудь про XP, TDD, рефакторинг, юнит-тестирование, профилирование, методы оптимизации, ООА&Д и ООП в конце концов. Но боюсь, после фразы " Тогда бы он(возможно) набивая код на ЯВУ,осуществлял бессознательную оптимизацию.", все мои заготовленные аргументы просто тонут в темноте...
Вот ещё "перлы":
"проблема ЯВУ не в обстрагировании от харда ))(каждому языку время и место ), а в постепенном наслоении халявы"
"В отличие от других языков програмирования-Ассемблёр имеет расширенный доступ"
"Но чем же не устраивает стандартный API? Ведь MFC - это ещё один уровень сверху, а значит новые тормоза!"
"Ну что ещё сказать,человек всегда выбирает то-что ему легче(теряя производительность)"
"А компиляторы бывают разные, они являются продуктом работы ЛЮДЕЙ, соответственно они могут содержать ошибки.
А ассемблЕрщик наверняка сможет решить проблему, не дожидаясь релиза нового компилятора(линкЁра)."
"В конце концов приходит C# и .NET и все ломают головы - "откуда тормоза? куда уходят ресурсы? почему уязвимости?".))"
Всего доброго, бодайтесь.
Люди твоего уровня ? Это те , наверно , которые в "Мелкосовте" сидят ? Они уж точно знают всё то что ты перечислил .)) Это сразу видно по переносу релиза лонгборна )). Особенно учитывая что перечисленные тобой ругательства при участии мелкомягких и придумали .)))
А если серьёзно - то вспомни откуда растут ноги у ошибки обработки строковых параметров . Такие ошибки я и имел в виду с своём посте .
И ещё : Си 5.0 вроде 32 битный . Но попробуйте вставить
ASM{mov eax,0}
в прогу и откомтилить без трансляции в асм файл .
Сразу видно полную 32 битность компилятора ))).
TDD, рефакторинг, юнит-тестирование, профилирование, методы оптимизации, ООА&Д и ООП - это безусловно придумка ламеров из майкрософт :D
koderAlex
TDD, рефакторинг, юнит-тестирование, профилирование, методы оптимизации, ООА&Д и ООП - это безусловно придумка ламеров из майкрософт :D
А ты как думал? И вообще, Windows - MUST DIE! Разьве это еще не все поняли? :D
ЗЫ А тему пора бы уже закрыть, или в Отдохнем перенести.
А ты как думал? И вообще, Windows - MUST DIE! Разьве это еще не все поняли? :D
ЗЫ А тему пора бы уже закрыть, или в Отдохнем перенести.
а еще суксь, давить и т.д., но я бы посмотрел на бухгалтерш, лишившихся ворда и ехеля... Хотя Лексикон хоть слова переносить может :)
а еще суксь, давить и т.д., но я бы посмотрел на бухгалтерш, лишившихся ворда и ехеля... Хотя Лексикон хоть слова переносить может :)
хотел бы я посмотреть на бухгалтера, который MS Office отличит от Open\StarOffice. а вот на дизайнера, которому вместо Photoshop GIMP подсунут я бы глянул. да и 1С пока еще незавменим :)
Ведь не секрет,что (почти) во всех офисах виндак стоит,и в интернет-кафе,а может и у вас дома?(Есди подумать)
Ну и небудет Виндака,тогда игры другие пойдут,все (наверное) на Линукс,интересно будет посмотреть на ЦС в линуксе :D ... Я не прав?
Складывается общее впечатление, что у людей представление об АссемблЕре где-то 20-летней давности.
Писать на асме не так уж и сложно(без оптимизации). Во всяком случае он не сложнее чем C++.
А даже проще. К тому же последнее время появилось достаточно много инструментов,
которые облегчают и ускоряют разработку на АссемблЕре.
А с утверждением об узкости сферы по применению АссемблЕра можно поспорить.
АСМ можно применять в любой сфере, даже такой как прикладное программирование. А о системном программировании, реверсинге, крэкинге и т.п. и говорить не надо.
Трудоёмкость, время написания программ - это зависит от разработчика, от его квалификации, опыта.
Говорить об использовании асма строго при решении узкого круга задач и его возможностях может только тот кто не смог в достаточной мере с ним ознакомиться.
Чтобы не быть голословным, вот несколько линков для желающих:
[color=sienna]
wasm.ru]www.wasm.ru
win.asmcommunity.net
visualassembler.com]www.visualassembler.com
[/color]
Удачи!!!
8)
Громкие названия для процедур предназначенных для уменьшения кол. ошибок на условную единицу кода . Я , кнешно , понимаю - от ошибок никто не застрахован . Но , возможно , не будь -ээээ- (например ) ООП так плохо обдуманно (реализовано), то меньше былобы "программеров" счетающих что программирование это связка некоторого количества компонентов в вижелбасике ( билдере , дельфи - неважно ) . ... И вообще раньше водка была крепче , девушки красивше и программеры лучше ))) .
Рефакторинг .... Оптимизация ....
Громкие названия для процедур предназначенных для уменьшения кол. ошибок на условную единицу кода .
<skip>
Пост явно показывает отсутствия даже общего представления о перечисленных вещах, и в частности даже общего представления об ООП.
Может, для начала позаниматься самообразованием, книжек почитать, ознакомиться, вникнуть...
А не нести некомпетентный бред, попахивающий... нет, разящий кустарщиной.
P.S. Всё... конец "жить дружно" :D
Пост явно показывает отсутствия даже общего представления о перечисленных вещах, и в частности даже общего представления об ООП.
Может, для начала позаниматься самообразованием, книжек почитать, ознакомиться, вникнуть...
А не нести некомпетентный бред, попахивающий... нет, разящий кустарщиной.
P.S. Всё... конец "жить дружно" :D
гы... не удержался??? обещался же самоликвидироваться из дискуссии? :D
ничего, то ли еще будет. через пару недель прийдет какой нибудь очередной светоч и, откопав эту тему, гордо заявит - круче всего кодить паяльником. потому что оптимальнее реализовывать все задачи на уровне схемотехники.
а другой скажет, что процессоры сосут, а круче микроконтроллеры.
а другой скажет, что процессоры сосут, а круче микроконтроллеры.
Конечно! А ты разьве по другому думаешь? Вот что будет с P4 и материнкой, если проц вынуть на ходу и вставить другой? А с контроллером и его материнкой - ничего. Даже прошивка не портится. Так что сие есть святая правда (про то, что процы отдыхают) ;)
хотел бы я посмотреть на бухгалтера, который MS Office отличит от Open\StarOffice. а вот на дизайнера, которому вместо Photoshop GIMP подсунут я бы глянул. да и 1С пока еще незавменим :)
Ну ладно тебе, я же не в серьез :) Касательно GIMP - конечно фишечек и рюшечек в нем намного меньше. Но один большой плюс (не только с моей точки зрения) в нем есть - интерфейс более продуманный и удобный.
Хоген, китайский мастер Дзен, жил один в маленьком храме в деревне. Однажды четыре странствующих монаха попросили его разрешить им разжечь костер и обогреться.
Когда они устроили костер, Хоген услышал, что они спорят об объективности и субъективности. Он присоединился к ним и сказал: "Вот большой камень. Как вы считаете, находится он внутри или вне нашего сознания?"
Один из монахов ответил:
"С буддистской точки зрения всякая вещь является воплощением сознания, так что по-моему, камень находится внутри сознания."
"Твоя голова, должно быть очень тяжелая,- сказал Хоген,- если ты таскаешь в своем сознании такие камни."
:)
[color=indigo]Дзенская история:[/color]
- Армяне лучше, чем евреи!
- Чем лучше то?
- Чем евреи!
Косноязыкий я )))
Ну ладно тебе, я же не в серьез :) Касательно GIMP - конечно фишечек и рюшечек в нем намного меньше. Но один большой плюс (не только с моей точки зрения) в нем есть - интерфейс более продуманный и удобный.
Более непонятного и глючного интерфейса я не встречал. Требуется всего лишь сменить цвет фона на картинке с цвета на прозрачный - так это через такую задницу делается - причем ещё и не с первого раза.
По теме. Если бы код на асме не требовал под каждый макрос/процедуру, а то и под каждую строку, многострочный комментарий с пояснением - чего в конкретный момент автор пытался сделать - цены бы ему не было. Представьте себе программу нормального объема, строк скажем 150000 - и в серединке что-нить типа копирования строчки - кто без комментов сообразит, что в итоге в этом коде происходить будет - до/после копирования... Придется экранчиков 10 назад промотать, а может и больше, - потом вперед, - а потом опять пялиться на строчки, с которых начал.
Язык для командной работы только в том случае, если все участвующие получили идентичные курсы, занимаются идентичными тасками, имеют оговоренную схему описания интерфейсов и пр. Иначе написать нормального объема проект - где-нить 50 человеколет хотя бы - будет весьма проблематично. Разве что пользователь/заказчик будет согласен перекрыть бюджет на порядок, чтобы провести раз 10 (или 50) фазу тестирования и исправления ошибок (они неизбежно возникнут в гораздо больших количествах, чем при ОО подходе).
Более непонятного и глючного интерфейса я не встречал. Требуется всего лишь сменить цвет фона на картинке с цвета на прозрачный - так это через такую задницу делается - причем ещё и не с первого раза.
У кого откуда руки ;)