форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
Сообщение от opennews (??) on 20-Мрт-13, 13:53
Опубликованы (http://tolszak-dev.blogspot.ru/2013/02/simple-qml-vs-efl-com...) результаты довольно обстоятельного сравнения особенностей разработки приложений с графическим интерфейсом пользователя при использовании Qt QML и EFL (Enlightenment Foundation Library). Сравнение охватывает такие вопросы, как удобство разработки, оценка трудозатрат, компактность кода, потребление памяти в процессе работы, скоросоть запуска, производительность итоговых приложений, визуальная привлекательность и т.п. Для оценки использовался клон игры Минёр, написанный с использованием QML и EFL. При использовании EFL и языка Си потребовалось написать примерно в два раза больше кода, чем при использовании QML/JavaScript (1487 и 668 строк кода).  QML/JavaScript отмечен как более высокоуровневое средство разработки, позволяющее создавать программы быстрее, чем при использовании языка Си. По возможностям Qt также заметно опережает EFL. При этом различия в производительности и потреблении ресурсов  оказались не такими заметными как можно было предположить. С позиции потребления памяти на 32-разрядной системе RSS приложения на EFL составил 15.8 Мб, а QML - 27.6 Мб, но при этом для EFL размер совместно используемых блоков составил 2.6 Мб, а для QML - 15.3 Мб. PSS для QML составил 27.5 Мб, а для EFL - 15.8.  В 64-разрядной конфигурации потребление памяти QML оказалось на несколько мегабайт ниже, чем EFL (PSS 18.6 и 20.7 Мб). При запуске одновременно 5  и 10 копий приложения различия в 32-разрядной конфигурации сгладились за счёт более активного совместного использования памяти в QML. <center><a href="http://4.bp.blogspot.com/-UI5X1AUuI-A/UThrDZ_qgpI/AAAAAAAAAN... src="http://www.opennet.dev/opennews/pics_base/0_1363772261.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center> <center><a href="http://4.bp.blogspot.com/-IfFhpgL_x6Y/UThrHVrnK7I/AAAAAAAAAN... src="http://www.opennet.dev/opennews/pics_base/0_1363772295.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center> Время запуска для приложений на EFL оказалось меньше, примерно на 30%. <center><a href="http://1.bp.blogspot.com/-44dmmZ_qRss/UThpCuRcRbI/AAAAAAAAAM... src="http://www.opennet.dev/opennews/pics_base/0_1363772520.png" style="border-style: solid; border-color: #606060; border-width: 1px;" title="" border=0></a></center> URL: http://tolszak-dev.blogspot.ru/2013/02/simple-qml-vs-efl-com... Новость: http://www.opennet.dev/opennews/art.shtml?num=36446
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
Сообщение от Аноним (??) on 20-Мрт-13, 13:53
> QML/JavaScript отмечен как более высокоуровневое средство разработки, Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага. Тогда как си за такое сразу послал бы на и был бы прав. А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Сравнение эффективности разработки интерфейсов с использован..."	+7 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 13:59
	>А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься. Вам таки нужно больше для создания интерфейса?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	3. "Сравнение эффективности разработки интерфейсов с использован..."	+7 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 14:11
	Есть же люди, которые логику приложению реализуют прямо в коде для работы с GUI, а потом месразбираются что они понавоязи.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 20-Мрт-13, 14:37
	Это не шуточная проблема, у нас примерно такое и есть, особенно нереально тяжело это  рефакторить. Нужен очень жесткий контроль по использованию js что бы не писали на нем слишком много. а так QML ниче, мне нравится.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	16. "Сравнение эффективности разработки интерфейсов с использован..."	+6 +/–
	Сообщение от Пиу on 20-Мрт-13, 14:55
	> Это не шуточная проблема, у нас примерно такое и есть, особенно нереально > тяжело это  рефакторить. Нужен очень жесткий контроль по использованию js > что бы не писали на нем слишком много. а так QML > ниче, мне нравится. я смотрю на все эти FirefoxOS, Tizen и прочие, и понимаю, что никакого контроля не получиться
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	17. "Сравнение эффективности разработки интерфейсов с использован..."	–4 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 14:58
	Я не понимаю как на этом можно сделать что-то сложнее калькулятора.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	24. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Anonim (??) on 20-Мрт-13, 15:34
	>Я не понимаю как на этом можно сделать что-то сложнее калькулятора. Вот тут http://www.youtube.com/watch?v=kvWeE3kurEQ люди делятся опытом
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	43. "Сравнение эффективности разработки интерфейсов с использован..."	+5 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 16:49
	Это не проблема js, это проблема людей. Чем более высокоуровневый язык - тем легче на нем быдлокодить, откладывая решение проблем с качеством кода на потом. Многие еще не могут понять сам js, что его парадигма сильно отличается от других ОO-языков, и шпарят на нем так, как они привыкли писать на C++. И GUI тут тоже ни при чем. На js уже давно можно решать задачи, отвязанные от GUI, и рефакторится он прекрасно. Другое дело, что пока в node.js юные хацкеры сильно косячат, создавая о js неправильное представление. Лучше стандарты CommonJS для начала почитать, прежде чем делать выводы. Другое дело еще, что сама Qt сильно на GUI завязана, что тоже в свою очередь создает неравильноt впечатление о js.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	81. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 23:28
	> Это не проблема js, это проблема людей. Это, конечно, проблема людей, но у компиляторов да еще с статической типизацией есть хорошая фича: они могут на фазе компиляции проверить валидность понаписанного и отловить совсем уж явные грабли. А в случае JS сделано все для того чтобы лажа прошла всю мыслимую авотматическую валидацию, т.к. как бы ничего и не нарушает. Все-таки настолько фундаментальные и неизлечимые "даже если явно захотеть" грабельки - это плоховато. > Чем более высокоуровневый язык - тем легче на нем быдлокодить, откладывая > решение проблем с качеством кода на потом. Это только усугубит проблему. > Многие еще не могут понять сам js, что его парадигма сильно отличается > от других ОO-языков, и шпарят на нем так, как они привыкли писать на C++. Если кто си++ нормально освоил - JS ему вообще будет на один зубок, имхо. Но вот так грубо обуть на все опции автоматического контроля синтаксической валидности например объявления переменных - это FAIL, как ни крути. > И GUI тут тоже ни при чем. На js уже давно можно решать задачи, отвязанные от GUI, Можно, но лучше не нyжно. Иначе нас задолбают кривые глюкастики с трудноуловимыми глюками. > и рефакторится он прекрасно. Да что там, предлагаю новый слоган: Written once. Debug everywhere. > Другое дело, что пока в node.js юные хацкеры сильно косячат, создавая о js > неправильное представление. Лучше стандарты CommonJS для начала почитать, > прежде чем делать выводы. Извините, стандарты это прекрасно, но если некто сравнивает гайки с бананами - JS это вообще не только не смутит. Еще и какой-то результат будет получен. Какой у него логический смысл - только рандому и известно. И программа где-то потом таки сломается, поскольку сделали явный бред, ломающий логику программы. А в паре мест быдлокодеры вообще написали "бананасы". Но этого тоже никто не заметит. Поскольку они на автомате создались и далее существовали. Хоть никто и не знает что это за фигня и почему она там была. С другой стороны, си например при попытке сравнить гайки с бананами по дефолту пошлет - мол, ты что, сдурел, гражданин?! Но если вы реально хотите это сделать - да си вообще до балды на самом деле. Можно гаркнуть "Считать гайки за бананы, знать ничего не знаю!" - тогда сравнивайте наздоровье. Но вас завернут если вы это сделаете нечаянно. Знаете, пистолет у которого совсем нет никакого предохранителя  и который по этому поводу стреляет когда попало - это хреновый, негодный пистолет. Он будет чаще простреливать части тела владельца. Что делает его довольно мазохистичной штукой. > Другое дело еще, что сама Qt сильно на GUI завязана, что тоже > в свою очередь создает неравильноt впечатление о js. Внезапно, Qt может быть собран без зависимости от графических подсистем :).
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	86. "Сравнение эффективности разработки интерфейсов с..."	+4 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 23:43
	> Если кто си++ нормально освоил — JS ему вообще будет на один зубок, имхо. только вот зуб сломается. большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. до финиша редкий кактус долетает. вообще-то «на один зубок» будет тому, кто знает Scheme (но будет ругаться матом за корявость).
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	124. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от mma on 21-Мрт-13, 15:35
	> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. тут как бы цель не оправдывает средства, это как в слона дробиной, посмотришь на все это и думаешь ну и зачем это тут в браузере.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	126. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:43
	>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. > тут как бы цель не оправдывает средства, это как в слона дробиной, > посмотришь на все это и думаешь ну и зачем это тут > в браузере. вот-вот. «зачем мне лопата, мне копать надо!» зато незнание не мешает им гордо говорить: «а, жабоскрип… знаю, за пол-часа выучил.» а потом показываешь им простой js-код — и наблюдаешь мёртвое зависание системы. с последующим выходом на арену OOM-киллера и воплями: «да этот ваш js вообще гуано, а не язык!» а знание-то куда-то испаряется.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	127. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:45
	>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. > тут как бы цель не оправдывает средства, это как в слона дробиной, > посмотришь на все это и думаешь ну и зачем это тут > в браузере. p.s. прототипная модель и замыкания, кстати, используются не только в js. даже в новый цпп попытались кусочек последнего протащить (вышло как обычно, правда, но это уже другая сказка). да и вообще. человек, считающий себя программистом, а не быдлокодером, про эти вещи знает и использовал, когда писал не на си.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	102. "Сравнение эффективности разработки интерфейсов с использован..."	+2 +/–
	Сообщение от angra (ok) on 21-Мрт-13, 03:03
	Судя понаписанному, js вы так и не смогли осилить, как в общем-то и C++. Проверка синтаксиса в js есть на стадии "компиляции", проверка типов в основном в рантайме, но я не сказал бы что это сильно усложняет отлов ошибок. А в С++ можно перегружать функции, что замечательно херит преимущества статической типизации, увеличивает вероятность возникновения и затрудняет поиск ошибок. Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь им все скриптовые языки на один зубок. Они такую херню на скриптовых языках пишут, что рука не покидает лица при просмотре. В доке по перлу для них даже специальные разъяснения добавили, чтобы хоть от самых частых фейлов избавить, но судя по коду, что мне попадается, помогает это слабо.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	103. "Сравнение эффективности разработки интерфейсов с..."	+3 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 03:06
	> Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь > им все скриптовые языки на один зубок. Они такую херню на > скриптовых языках пишут, что рука не покидает лица при просмотре. это да. поскольку они знают только о молотке, то любым инструментом пытаются пользоваться как молотком. получается обычно плохо. что характерно, при этом они не себя винят в том, что неправильно инструмент используют, а инструмент в том, что он не молоток. очень сильно js этим страдает, кстати. отчего-то многие уверены, что js — это такой простой язык, который и учить-то не надо. а то, что по идеологии он ближе к схеме и смолтолку… фигня, всё равно молотком будет.
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	121. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от TbIK (ok) on 21-Мрт-13, 13:41
	В защиту си/сипиписников (коим я был лет 20 назад), скажу: зато эти люди никогда не попадают в ловушки несоответствия концепций и железа (что встречается сплошь и рядом). Жабоскрипт прячет кучу деталей под себя и у вновь обученных создаёт ложное ощущение простоты и быстроты кодинга. Тем более это опасно для новичков, не прошедших "школу ассемблера" - у них в голове расхлябаная концепция "чо хочу - то ворочу". Надо быть очень маститым прогером вообще, прежде чем его можно допускать до жабоскриптовых вольностей. Это сродни ЛИСПу в мире ООП: можно столько всего наворотить, что впору одевать каждому смирительную рубашку, дабы эти "навороты" не опрокинули потом какой-нть "интыпрайз".
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	128. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:47
	> эти люди никогда не попадают в ловушки несоответствия концепций и железа i lol'd hardly.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	112. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от jOKer (ok) on 21-Мрт-13, 07:51
	>А в случае JS сделано все для того чтобы лажа прошла всю мыслимую авотматическую валидацию Освойте для себя сервис-ориентированные архитектуры, разместите бизнес-логику на (допустим) RESTfull веб-сервисах, оставив на долю js только gui, и будет вам щастье. Много-много щастья. >Если кто си++ нормально освоил - JS ему вообще будет на один зубок, имхо. Улыбнул, приятель))) Думаю, что этот свой "зубок" православный си-шник будет оттачивать не один месяц. Да и отточит ли - еще вопрос. >Да что там, предлагаю новый слоган: Written once. Debug everywhere. > А в паре мест быдлокодеры вообще написали "бананасы". Но этого тоже никто не заметит. Внезапно: проблему "бананасов" можно извести почти до нуля грамотно построенным юнит-тестом. А в качестве примера тулкита, в котором отличная долговременная поддержка кода, платформа автоматического тестирования и т. д. можно привести dojo. И, думается мне, что не только его. Просто быдлокодеры этим не парятся и пишут свои поделия на коленке (хых: пожалуй даже на переменке)... ну и результат соответствующий))
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	113. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 08:03
	проблемы бананасов сводятся почти к нулю простым линтером. написать который для seasoned c/c++ programmer — пара дней работы. с пивом. однако же Зубры ЦыПыПы больше любят кактусы, поэтому едят. и, конечно, свято уверены, что раз они, Зубры, жрут кактусы — то и все остальные жрут кактусы. ведь не может же так быть, чтобы кто-то был умнее, да прекрасней и милее. p.s. проще говоря: «некогда за лопатой бегать, копать надо, и так пальцы болят!»
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	9. "Сравнение эффективности разработки интерфейсов с использован..."	+5 +/–
	Сообщение от Пиу on 20-Мрт-13, 14:25
	проблема в том, что орава жабопогромистов ничего более не умеет, но хочет жрат
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	18. "Сравнение эффективности разработки интерфейсов с использован..."	–3 +/–
	Сообщение от Xasd (ok) on 20-Мрт-13, 15:02
	> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет > жрат проблема в том что C/C++-программисты настолько умные, и настолько много всего держут у себя в голове когда разрабатывают программу [например держут в голове информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами и не забывают опустошать циклические связи между объектами (используя слабые ссылки там где надо, и не используя так где не надо!)].... ....что у них совсем не остаётся времени на продумывание таких банальных вещей как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность этого события. (да! событие пришло в обработчик события! но это НЕ обозначает что нужно его сразу же обрабатывать! вдруг уже позно его обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже успел запустить протеворечивый механизм?) бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи, а из-за тормозов компьютера или из-за тормозов интернета -- программа не в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае программа не должна продолжать делать то что УЖЕ делать нет нужды. и таких вот мелочей -- в программах бывает очень много! и программисту первым делом нужно именно обращать внимание НА ЭТО, а не на то насколько красивым выглядит структура того или иного объекта, или насколько канонически верно сделана операция пере-балансировки бинарного дерева.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	23. "Сравнение эффективности разработки интерфейсов с использован..."	+2 +/–
	Сообщение от Пиу on 20-Мрт-13, 15:28
	>> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет >> жрат > проблема в том что C/C++-программисты настолько умные, и настолько много всего держут > у себя в голове когда разрабатывают программу [например держут в голове > информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами > и не забывают опустошать циклические связи между объектами (используя слабые ссылки > там где надо, и не используя так где не надо!)].... а программисты на жаваскрипте структуру программы в голове не держат? х**к-х**к и в продакшн? > ....что у них совсем не остаётся времени на продумывание таких банальных вещей > как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность > этого события. (да! событие пришло в обработчик события! но это НЕ > обозначает что нужно его сразу же обрабатывать! вдруг уже позно его > обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже > успел запустить протеворечивый механизм?) вдруг-вдруг-вдруг, не говоря уже о том, что проблема высосана из пальца > бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи, > а из-за тормозов компьютера или из-за тормозов интернета -- программа не > в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае > программа не должна продолжать делать то что УЖЕ делать нет нужды. вообще-то мы о десктопе говорим, какой интернет? > и таких вот мелочей -- в программах бывает очень много! и программисту > первым делом нужно именно обращать внимание НА ЭТО, а не на > то насколько красивым выглядит структура того или иного объекта, или насколько > канонически верно сделана операция пере-балансировки бинарного дерева. у вас совершенно случайные знания, о том чем занимаются C++ программисты, да и программисты вообще. базвордами типа "бинарное дерево" советую не кидаться, ибо уже видно что вы плаваете в теме
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	31. "Сравнение эффективности разработки интерфейсов с использован..."	+6 +/–
	Сообщение от тоже Аноним (ok) on 20-Мрт-13, 16:05
	Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!". Настоящий юзер-френдли интерфейс, безусловно, должен понимать такие очевидные вещи. Жаль, что использование тех или иных технологий само по себе таким знанием интерфейс не обогатит.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	37. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Пиу on 20-Мрт-13, 16:27
	>Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!". проблема в том, что интерфейс в результате должен обладать телепатией, чтобы отличить случаи "нужно было 5 раз" и "нужно было 1 раз, но .." алсо, лично я считаю интерфейс который такое позволяет вредным. он создает армию тупых людей
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	41. "Сравнение эффективности разработки интерфейсов с использован..."	–2 +/–
	Сообщение от mr. green thumb on 20-Мрт-13, 16:46
	вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	44. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Пиу on 20-Мрт-13, 16:50
	> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои > розовые очки это проблема программы? программа должна учитывать, что у пользователя заклинило клавишу, поломалась одна ось вращения мыши и прочее? ок, пишите четко ТЗ, если мы делаем прошивку космического аппарата, ну и платите соответственно
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	48. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 20-Мрт-13, 17:00
	> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки с какой вероятностью клавишу заклинит у умного человека, и с какой вероятностью заклинит глупого человека, даже если с клавишами у него все в порядке то что вы мыслите на уровне всегда-никогда, рассуждая про розовые очки, степень ума неплохо характеризует
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	52. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от qqq (??) on 20-Мрт-13, 17:25
	Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не клиентские приложения
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	75. "Сравнение эффективности разработки интерфейсов с использован..."	+5 +/–
	Сообщение от Vkni (ok) on 20-Мрт-13, 22:48
	> Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не > клиентские приложения Вы не поверите, но это должен разруливать человек, только он может поменять клавиатуру или вычистить замусоренную. :-)
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	65. "Сравнение эффективности разработки интерфейсов с..."	+3 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 20:54
	> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои > розовые очки а ещё есть вариант «половина клавиатуры не работает! ваша программа говно, не могу половину букв набрать!» кстати, о забавных багах: если в опере быстро-быстро сделать двойной правоклац на пустом месте страницы, то контекстное меню она покажет, но убрать его кликом «мимо меню» будет нельзя. или esc с клавиатуры, или выбрать действие. такой финт можно провернуть, когда опера над чем-то задумалась и не успела сразу на вызов меню отреагировать.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	83. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 20-Мрт-13, 23:34
	> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки Ага, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг в руки.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	117. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 21-Мрт-13, 13:06
	>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки > Ага, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг > в руки. Демагогия.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	129. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:48
	>>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки >> Ага, «да чтоб у тебя ресет заклинил». Чини это потом программно, флаг >> в руки. > Демагогия. причём началась она с поста «а если клаву заклинит?!»
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	57. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 20-Мрт-13, 18:42
	> Вам таки нужно больше для создания интерфейса? А это сильно зависит от интерфейса. Если это интерфейс для дебильника или автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических редакторов или там еще чего посложнее hello world-а - бывают и достаточно нетривиальными.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	101. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Led (ok) on 21-Мрт-13, 02:57
	>> Вам таки нужно больше для создания интерфейса? > А это сильно зависит от интерфейса. Если это интерфейс для дебильника или > автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс > например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических > редакторов или там еще чего посложнее hello world-а - бывают и > достаточно нетривиальными. Например, XUL?
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	104. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 03:07
	> Например, XUL? или так, да — дебильными.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	122. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 21-Мрт-13, 14:30
	>Вам таки нужно больше для создания интерфейса? А кто сказал, что JS только  для интерфейса?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Сравнение эффективности разработки интерфейсов с использован..."	–4 +/–
	Сообщение от Ы on 20-Мрт-13, 14:17
	невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	11. "Сравнение эффективности разработки интерфейсов с использован..."	+3 +/–
	Сообщение от Пиу on 20-Мрт-13, 14:29
	> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка динамическая типизация - это отличный способ выстрелить себе в ногу или словить "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс строго не задан
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	12. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Ы on 20-Мрт-13, 14:35
	угу для этого её и придумали, давайте приводить ещё возможности накосячить
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	14. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Xasd (ok) on 20-Мрт-13, 14:39
	>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка > динамическая типизация - это отличный способ выстрелить себе в ногу или словить > "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс > строго не задан тоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) .. говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку" -- особо ничего плохого случиться не может. а вот случай "забыл сконвертировать число в строку" будет сразу заметен в течении 5 минут работы программы. от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов..
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	15. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Пиу on 20-Мрт-13, 14:53
	>тоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) .. функция требует два аргумента, их тип не задан, это же динамическая типизация >от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов.. фигасе, "кроме случая". у большинства функций разнородные аргументы вообще-то
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	19. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Xasd (ok) on 20-Мрт-13, 15:11
	> у большинства функций разнородные аргументы вообще-то типа как:     объект, число, число, число или , например     объект, число, число ??? по моему это не совсем разнородные :-) редкий случай когда напимер 3 аргумента и все разнородные
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	22. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Пиу on 20-Мрт-13, 15:19
	>> у большинства функций разнородные аргументы вообще-то > типа как: >     объект, число, число, число > или , например >     объект, число, число > ??? еще раз, не везде аргументы функции состоят из наборов чисел. более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API) >редкий случай когда напимер 3 аргумента и все разнородные далеко не редкий
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	39. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от souryogurt (ok) on 20-Мрт-13, 16:34
	>> более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API) Почему?
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	42. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Пиу on 20-Мрт-13, 16:47
	потому что их легко перепутать ;)
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	72. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от VoDA (ok) on 20-Мрт-13, 22:37
	>> у большинства функций разнородные аргументы вообще-то > типа как: >     объект, число, число, число > или , например >     объект, число, число > ??? > по моему это не совсем разнородные :-) Чаще объект, объект, объект. Внутри, конечно, будут числа, но не всегда первым уровнем. PS еще и список объектов в функцию можно передавать. А уж замыкание так это вообще легко ;)
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	66. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 20:58
	> от перепутанных местами параметров — статическая типизация тоже (как и динамическая) не > защищает кстате.. а вот в Smalltalk это решили очень изящно. и без проверки типов.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	73. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от VoDA (ok) on 20-Мрт-13, 22:43
	>>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка >> динамическая типизация - это отличный способ выстрелить себе в ногу или словить >> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс >> строго не задан > тоесть например функция требует объект <Кнопка> , а мы передадим туда объект > <Временная_Константа>? и как же это может произойти на практике? :-) .. > говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку" У меня в практике были косяки типа кодил-кодил - все работало. Зашел на соседний экран - упало. Причем с кривейшей ошибкой. Довольно долго втыкал и матерился, пока не пошел сплошняком проверять файлы. И оказалось, что рядом с одним из описаний объектов затесался спец-символ (когда переключал экраны кнопку зацепил). То ли . то ли ; и, как следствие, отвалило одно из полей. Но это стало заметно не сразу, а через продолжительный период времени. Печаль =( Не люблю JS за невозможность провалидировать корректность кода в процессе программирования (до запуска на исполнение).
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	76. "Сравнение эффективности разработки интерфейсов с..."	+2 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 22:49
	тут дело-то в том, что js никогда и не задумывался как язык для разработки большого софта. а теперь его обвешивают костылями и пихают невпихуемое.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	118. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Аноним (??) on 21-Мрт-13, 13:07
	> тут дело-то в том, что js никогда и не задумывался как язык > для разработки большого софта. а теперь его обвешивают костылями и пихают > невпих/емое. Ничего не напоминает?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	125. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:41
	>> тут дело-то в том, что js никогда и не задумывался как язык >> для разработки большого софта. а теперь его обвешивают костылями и пихают >> невпих/емое. > Ничего не напоминает? много всякого напоминает. но беседа-то у нас про js.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	82. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от piteri (ok) on 20-Мрт-13, 23:29
	>и как же это может произойти на практике? Легко >будет сразу заметен в течении 5 минут работы программы. После установки заказчику.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	114. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от jOKer (ok) on 21-Мрт-13, 08:07
	>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка > динамическая типизация - это отличный способ выстрелить себе в ногу или словить > "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс > строго не задан Давайте все-таки не путать динамическую/статическую типизацию и строгую/мягкую типизацию. Внезапно: есть ЯП в которых реализована строгая динамическая типизация. И в этих ЯП автоматического приведения к типу нет, а вот замыкания, инжекция кода и прочие вкусняшки, - напротив, имеются. ЗЫ. А "борцам" с динамической типизацией из-за того, что у них автоматически привелись типы, а они это прощелкали, надо выстрелить не в ногу, а в голову - все равно она им не к чему.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	115. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 08:14
	отчасти-то он прав. потому что новоявленые МегаГуру про контракты, может, и слышали, но в виду отсутствия мозга ничего не поняли. соответственно, хвалёные библиотеки часто вместо контрактов светят половым гениталием. это ж «тормозит» и вообще «лишний код». с другой стороны — за отсутствие булевого типа и использование «+» для соединения строк таки надо было бы лишить обеда. и ужина.
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	49. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 17:10
	А в каких языках динамическая типизация НЕ ВОЗМОЖНА?
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	55. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от exist (ok) on 20-Мрт-13, 18:15
	Видимо, в языках со строгой типизацией. Например, Ada.
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	116. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 21-Мрт-13, 12:12
	Мягкое и теплое, ага. В Python динамическая строгая типизация.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	130. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 17:56
	> Мягкое и теплое, ага. В Python динамическая строгая типизация. хорошая шутка.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	134. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Аноним (??) on 22-Мрт-13, 14:12
	Плохой юмор.Кто-то (не будем показывать пальцем) путает статическую и строгую типизацию. http://ru.wikipedia.org/wiki/%D0%A1%D1%8... $python >>> a = '2' >>> b = a + 2 Traceback (most recent call last):   File "<input>", line 1, in <module> TypeError: cannot concatenate 'str' and 'int' objects >>>
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	136. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от arisu (ok) on 22-Мрт-13, 16:13
	a = «fuck»; a = 40; print a+2; опа. это — не строгая типизация. какого хрена у 'a' — разные типы во время выполнения программы? да, строгой без статики — увы. смиритесь. впрочем, вколачивать ум в черепа любителям гвидобейсика — занятие неблагодарное. поэтому удаляюсь, бисера жаль.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	58. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 20-Мрт-13, 18:43
	> ВОЗМОЖНОСТЬ динамической типизации это плюс языка Только если ее делать не через опу. Т.е. с возможностью форсануть статическую для уменьшения грабель. А тут мало того что типизация динамическая, так еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект потом замахаешься дебажить в поисках опечатки.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	135. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 22-Мрт-13, 14:32
	>> ВОЗМОЖНОСТЬ динамической типизации это плюс языка > Только если ее делать не через опу. Т.е. с возможностью форсануть статическую > для уменьшения грабель. А тут мало того что типизация динамическая, так > еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки > кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект > потом замахаешься дебажить в поисках опечатки. Приведите пример крупного проекта по созданию интерфеса программы.
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	7. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Xasd (ok) on 20-Мрт-13, 14:20
	> JS создал на автомате... как это он создал на автомате? кто ему разрешил самодеятельность? или мы рассматриваем случай когда программист забыл добавить 'use strict' в начало файла?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	10. "Сравнение эффективности разработки интерфейсов с использован..."	+4 +/–
	Сообщение от Xasd (ok) on 20-Мрт-13, 14:25
	> ...си за такое сразу послал бы... анализатор статической типизпции -- не сделает за программиста его работу. если ты написал (по ошибке) memset(my_obj_ptr, 0, sizeof(my_obj_ptr)); вместо memset(my_obj_ptr, 0, sizeof(*my_obj_ptr)); то компилятор тебя не пошлёт (и темболее "сразу"). иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки. однако статическая компиляция не палочка-выручалочка. по большей части она в основном только указывает на то что "чувак, ты хочешь же вывести на экран строку, а передаёшь в параметре число... ну забыл сконвертировать же!", а не на какую-то серъёзную штуку, которая годами может себя не проявлять.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	50. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от qux (ok) on 20-Мрт-13, 17:18
	> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки. Некоторые не знаю, а в общем, как и все прочие, страдают забиванием. Сравнить, например, кол-во полезных подсказок, выдаваемых gcc на не-helloworld по дефолту и с -Wall -Wextra (-pedantic --std=c99 -Werror). А потом кол-во проектов, которые ближе ко второму. Особенно коммерческих.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	61. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Алексей Морозов (ok) on 20-Мрт-13, 18:52
	> memset(my_obj_ptr, 0, sizeof(my_obj_ptr)); Ну, вот конкретно такое достаточно хорошо ловится юниттестами, запущенными под валгриндом
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	74. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Vkni (ok) on 20-Мрт-13, 22:46
	> анализатор статической типизпции -- не сделает за программиста его работу. Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор и динамическое типизирование.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	78. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 20-Мрт-13, 22:51
	>> анализатор статической типизпции — не сделает за программиста его работу. > Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор > и динамическое типизирование. не соглашусь. другое дело, что в js нет встроеного механизма указать типы, если надо. зато есть идиотия с использованием одного и того же оператора для сложения строк и чисел.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	90. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от Vkni (ok) on 21-Мрт-13, 00:02
	> не соглашусь. другое дело, что в js нет встроеного механизма указать типы, > если надо. зато есть идиотия с использованием одного и того же > оператора для сложения строк и чисел. Сравни OCaml и JS: в первом система статических типов, вывод типов методом ХМ (т.е. указывать тип можно, но не обязательно - он будет выведен), именованные параметры, значения параметров по-умолчанию. Единственная фигня - операторы для вещественных чисел /., *., +. и -., хотя никто не мешал перегрузить. Это, впрочем, исправлено в F#.
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	92. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 00:16
	> Сравни OCaml и JS я окамла не знаю, увы. ну, так — на уровне «о! окамл! я не испуган, но озадачен.» впрочем, сравнение всё равно некорректно: всё-таки js изначально не планировался как язык для написания чего-то сложнее, чем небольшие скриптики. в actionscript это попытались починить, но зачем-то притащили и симула-подобную (точнее, цпп-подобную) объектную модель. (да, я знаю, что дефис не нужен; но с ним красивей) беда js в том, что никто изначально не предполагал масштабов бедствия. а в итоге современные реализации js, например, должны бережно повторять глюки оригинального дизайна. с var, например, у которого scope — вся функция, а не блок. или с тем, что eval (который и так-то не особо нужен, но…), присвоеная переменной — уже не совсем та же самая eval.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	93. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от Vkni (ok) on 21-Мрт-13, 00:32
	> я окамла не знаю, увы. ну, так — на уровне «о! окамл! > я не испуган, но озадачен.» Посмотри, не пожалеешь - штука маленькая, быстрая и очень удобная. Учебник по OCaml - http://caml.inria.fr/pub/docs/oreilly-book/ (где-то есть перевод на русский). Сочетает императивщину и функциональщину. И его идеи - более-менее передний край CS, как говорят специалисты, в 90-е научное развитие языковых средств остановилось (а индустрия это постепенно подсасывает). После этого будет тяжко смотреть на С++ с его шаблонами и смешно на тутошние языковые споры. > беда js в том, что никто изначально не предполагал масштабов бедствия. Есть ещё чудесный PHP. :-)
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	94. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 00:49
	>> я окамла не знаю, увы. > Посмотри, не пожалеешь — штука маленькая, быстрая и очень удобная. да я знаю это — теоретически. а на практике как-то всё лениво, каждый раз на завтра откладываю. > где-то есть перевод на русский это не обязательно. %-) > После этого будет тяжко смотреть на С++ с его шаблонами да мне давно смешно. > и смешно на тутошние языковые споры. и так… собственно, после Scheme, где спокойно сочетается императивщина, функциональщина, разные объектные модели и pattern matching… разве только системы типов нет, хотя type inference поверх компилятора повесить несложно, code as data же. >> беда js в том, что никто изначально не предполагал масштабов бедствия. > Есть ещё чудесный PHP. :-) нененене. на js всё-таки можно писать, хоть и с трудом. но есть замыкания, лямбды и прочие приятные вещи. а у php одни костыли из каждой дырки и 100500 функций в global namespace. %-)
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	95. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Crazy Alex (ok) on 21-Мрт-13, 01:11
	В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к одному.
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	96. "Сравнение эффективности разработки интерфейсов с..."	+2 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 01:14
	> В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к > одному. да у них у всех ноги из одного места растут.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	77. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 22:50
	> если ты написал (по ошибке) > memset(my_obj_ptr, 0, sizeof(my_obj_ptr)); > вместо > memset(my_obj_ptr, 0, sizeof(*my_obj_ptr)); Во-первых, где здесь статическая типизация? Перепутана константа. Во-вторых, некоторые компиляторы выдают warning при компиляции такого (в gcc, вроде, было).
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	91. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Vkni (ok) on 21-Мрт-13, 00:05
	> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием > из-за того что думают будто компилятор находит все их ошибки. С момента изобретения С прошло уже 40 лет, пора бы и на другие языки посмотреть. В частности, на ML/Haskell и подобные - там значительно более серьёзная система типов, нежели в С. И результаты работы анализатора типов, разумеется, тоже более серьёзные. Он тоже не найдёт все ошибки, но результат явно будет лучше, чем в С, где можно поменять в memset 2 последних параметра местами и это пройдёт.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	97. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Crazy Alex (ok) on 21-Мрт-13, 01:18
	Ну тогда уже D порекламирую, благо он нынче вполне приятен. И вывод типов есть, и если надо в кишки залесть - пишешь unsafe и понеслось. А уж ranges - совершенно чудесная штука, которую никто, кажется, больше не сделал. И не заставляет ломать мозг функицональщиной вида "ехал лямбда через рекурсию монадой погоняя". При этом при надобности есть и иммутабельность, и алгебраические типы, и pure-функции, и карринг, и много других страшных слов :-)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	99. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 01:35
	не хватает только стандарта и нескольких компиляторов. кагбэ D1 уже нет, а D2 ещё толком нет. и нераспространено. но в остальном — надеюсь, что он в конце концов вытолкает цпп на обочину истории и легаси-кода.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	131. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от TbIK (ok) on 21-Мрт-13, 19:03
	> не хватает только .... Немного не так: кто ХОЧЕТ писать - тому всего хватает. Кто не хочет - тому ВЕЧНО чего-то нехватает, "мешается в танце" и т.п. > D2 ещё толком нет. Есть. Работающий компилятор, бери, да пользуйся! > и нераспространено. Как и любой язык без тонны говномаркетинга и бабла. Но при наличии разумных прогеров, легко вольётся в ряды. Вы же про него уже знаете! Я несколько перделок написал. Другие тоже не останутся в стороне, сравнив его с сипипями и цэшарпами.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	132. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 19:25
	>> не хватает только …. > Немного не так: кто ХОЧЕТ писать — тому всего хватает. Кто не > хочет — тому ВЕЧНО чего-то нехватает, «мешается в танце» и т.п. если ты пишешь себе приветмиры — то не вопрос, хоть для кнутовой шестибитовой машины пиши. >> D2 ещё толком нет. > Есть. Работающий компилятор, бери, да пользуйся! «есть» — это когда есть хотя бы две равноценные реализации и документ, на котором они базируются. >> и нераспространено. > Как и любой язык без тонны говномаркетинга и бабла. в си очень много вливали, да. и рекламировали на каждом углу. > Но при наличии разумных прогеров, легко вольётся в ряды. в качестве тестера — натурально. ничего плохого в этом нет, но мне неинтересно. > Вы же про него уже знаете! я про него знаю ещё с тех пор, как Уолтер его только сочинял. > Я несколько перделок написал. Другие тоже не останутся в стороне, > сравнив его с сипипями и цэшарпами. вот когда «не останутся» — тогда и стоит рассматривать в качестве языка для будущего проекта. а пока что вероятность подключения энтузиастов к проекту на c/c++ намного больше, чем та же вероятность для проекта на D. как минимум в силу того, что последних сильно меньше.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	133. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 19:27
	p.s. вообще, *лично для меня* язык подобного плана стоит более-менее серьёзно рассматривать тогда, когда в стандартном наборе gcc появится компилятор для этого языка.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

	105. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Led (ok) on 21-Мрт-13, 03:10
	>> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием >> из-за того что думают будто компилятор находит все их ошибки. > С момента изобретения С прошло уже 40 лет, пора бы и на > другие языки посмотреть. В частности, на ML/Haskell и подобные - там > значительно более серьёзная система типов, нежели в С. А разве в C есть что-то кроме char, int и float? Других типов нет - только "модификаторы" для указанных. Назвать это "системой типов"... мягко говоря, смешно.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	106. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 03:13
	> А разве в C есть что-то кроме char, int и float? да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что не надо уж совсем старичка унижать, он местами ещё вполне ничего.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	107. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Led (ok) on 21-Мрт-13, 03:21
	>> А разве в C есть что-то кроме char, int и float? > да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что > не надо уж совсем старичка унижать, он местами ещё вполне ничего. Никто его и не унижает. Но и превозносить его как божественное откровение и идеал - не стОит.
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	108. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 03:31
	> Никто его и не унижает. Но и превозносить его как божественное откровение > и идеал — не стОит. но в нише «переносимый макроассемблер» у него таки конкурентов нет.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	109. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Vkni (ok) on 21-Мрт-13, 04:45
	> но в нише «переносимый макроассемблер» у него таки конкурентов нет. Вообще, можно было бы и улучшить косметически - сделать вывод типов, убрать неявные преобразования. А так - да, ассемблер.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	110. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от arisu (ok) on 21-Мрт-13, 06:05
	нененене, не надо. а то мне будет скучно на нём писать. ;-)
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	111. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от Led (ok) on 21-Мрт-13, 06:58
	>> Никто его и не унижает. Но и превозносить его как божественное откровение >> и идеал — не стОит. > но в нише «переносимый макроассемблер» у него таки конкурентов нет. Нет. К сожалению.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	25. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 15:38
	>Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага. Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт... да хоть на Фортране!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	51. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от qux (ok) on 20-Мрт-13, 17:19
	Тогда уже гуй на вебе, портабельности ради.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	59. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 18:44
	> Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт... А чем глюки в гуе лучше глюков в счете?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	62. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от qux (ok) on 20-Мрт-13, 19:11
	Очевидно, при глюках в гуе иногда можно взять другой, или CLI-вариант, над которым был гуй.
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	33. "Сравнение эффективности разработки интерфейсов с использован..."	–2 +/–
	Сообщение от ВовкаОсиист (ok) on 20-Мрт-13, 16:10
	Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю программу на js. Хотя всем наплевать, все побежали быстро все переписывать на js, qml-же!
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	140. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от Аноним (??) on 22-Мрт-13, 19:59
	> Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и > в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю > программу на js. Хотя всем наплевать, все побежали быстро все переписывать > на js, qml-же! Ну и как на xml подстветить неправильно заполенные поля при вводе?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	141. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 22-Мрт-13, 20:19
	> Ну и как на xml подстветить неправильно заполенные поля при вводе? точно так же, как и без него. тот, кто делает валидатор исключительно средствами GUI и его языка — идиот. а в нормальном случае всё равно понадобится механизм, при помощи которого основная софтина будет отмечать такие поля.
	Ответить | Правка | ^ к родителю #140 | Наверх | Cообщить модератору

	53. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от CR on 20-Мрт-13, 17:28
	> через полчаса счета Какого еще "счета"? QML/JavaScript предназначены для создания GUI. "Счет" пиштеся как обычно - на C/C++.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
Сообщение от Xasd (ok) on 20-Мрт-13, 14:16
> Сравнение охватывает такие вопросы, как удобство разработки, оценка трудозатрат, компактность кода, потребление памяти в процессе работы, скоросоть запуска, производительность итоговых приложений, визуальная привлекательность и т.п. Для оценки использовался Капитан Очевидность fixed :)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Сравнение эффективности разработки интерфейсов с использован..."	–2 +/–
Сообщение от Аноним (??) on 20-Мрт-13, 14:17
А почему QML, а не чистый Qt?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Anonymus.UA on 20-Мрт-13, 14:25
	Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям...
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	63. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от anonymous (??) on 20-Мрт-13, 19:54
	>Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям... Где ты увидел в Qt чистый си? Развелось тут неучей, понимаешь.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

21. "Сравнение эффективности разработки интерфейсов с использован..."	+5 +/–
Сообщение от Mihail Zenkov (ok) on 20-Мрт-13, 15:19
Их саперы занимают памяти больше, чем ядро :(
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	60. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 18:46
	> Их саперы занимают памяти больше, чем ядро :( Ну так ядро писали нормальные системщики, на сях, без халтуры. А это апликушники. Раздолбаи и пофигисты. Которых хлебом не корми, дай только индусский код понаписать.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

34. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
Сообщение от ВовкаОсиист (ok) on 20-Мрт-13, 16:15
Я правильно понимаю, что они сравнили императивный стиль программирования с декларативным? Или JS с Си? Тогда реквестирую сравнение Qt-C++ vs QML+js.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Часть нити удалена модератором

	47. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от mr. green thumb on 20-Мрт-13, 16:53
	подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс или можно в свободное время?
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	54. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Michael Shigorin (ok) on 20-Мрт-13, 18:00
	> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	120. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Аноним (??) on 21-Мрт-13, 13:11
	>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс > Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего... Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище....
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	123. "(offtopic) microsoft student partners are NOT welcome"	+1 +/–
	Сообщение от Michael Shigorin (ok) on 21-Мрт-13, 15:15
	>>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс >> Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего... > Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище.... Паства тут ни при чём, поскольку вопрос технический, а не духовный (и я сам паства).  А с коллегами тут единодушен -- вещатели "правды", в том числе Вы лично, и тем более дешёвой рекламы MS -- здесь невостребованы вместе со своим (если вообще своим) мнением.  Научитесь _слышать_, а не только вещать -- приходите. Сколько раз это надо повторить, чтобы дошло? PS: слово "правда" забрано в кавычки потому, что выставляете как правду либо неправду, либо смесь правды с ложью; либо недоговариваете.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

56. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
Сообщение от Аноним (??) on 20-Мрт-13, 18:40
>>При этом различия в производительности и потреблении ресурсов оказались не такими заметными как можно было предположить. А вес фрэймворка интересно сравним?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

64. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
Сообщение от arisu (ok) on 20-Мрт-13, 20:48
очень ценное сравнение от человека, который: «Please note these are only my guesses — guesses of developer neither much experienced in plain C nor in EFL.» в принципе, дальше и разбирать неинтересно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	67. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от skybon (ok) on 20-Мрт-13, 21:19
	Бенчмарк может произвести и непрограммист. Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	68. "Сравнение эффективности разработки интерфейсов с..."	+2 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 21:31
	> Бенчмарк может произвести и непрограммист. ага. а домоходяйка — управлять государством. > Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть > — факт. это не факт, это теория. то, что яростные обличители и находители простоты не знают, как работает Edje и Embryo, и как создаются интерфейсы в EFL — даже не удивительно. удивительно было бы, если бы знали.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

	69. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 22:01
	офтоп > ага. а домоходяйка — управлять государством. Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно. а по теме - сравнивать довольно небольшой набор C библиотек и огромный плюснутый qt/qml - бред. еще больший бред кодить интерфейсы на C. Гр. интерфейс по своей природе декларативен. и стараться писать его в 21 веке надо в чём угодно, только не в императивных языках.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	71. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 20-Мрт-13, 22:23
	> Видимо удобно. ну, гейтсу же приписывают высказывание про 640 кб. пусть и ленин пострадает. > а по теме — сравнивать довольно небольшой набор C библиотек и огромный > плюснутый qt/qml — бред. сравнивали удобство создания морды как раз, и сопряжения её с логикой. тут как раз всё более-менее нормально. > еще больший бред кодить интерфейсы на C. именно поэтому в EFL так делают только любители Elementary. для Edje морда делается на Embryo и описывается местами похоже на qml. там внутри почти pawn есть, специально для всяких нестандартных переходов и анимашек. но можно и без него, получается всё равно симпатично. конечно, морду можно заменять, вплоть до вообще переделать. > Гр. интерфейс по своей природе декларативен. ровно до тех пор, пока декларации поддерживают хотелки. как только хотелки выходят за рамки — начинается разного рода битьё в бубен.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	79. "Сравнение эффективности разработки интерфейсов с..."	+2 +/–
	Сообщение от Аноним. on 20-Мрт-13, 22:58
	>Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно. Тогда уж будьте добры сами цитировать правильно и не придумывать не существующих концов. "Мы не утописты. Мы знаем, что любой чернорабочий и любая кухарка не способны сейчас вступить в управление государством. Но мы требуем немедленного разрыва с тем предрассудком, будто управлять государством, нести будничную, ежедневную работу управления в состоянии только богатые или из богатых семей взятые чиновники." «Удержат ли большевики государственную власть?» 1917.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	80. "Сравнение эффективности разработки интерфейсов с..."	+1 +/–
	Сообщение от arisu (ok) on 20-Мрт-13, 23:26
	ну, *по сути* он правильно сказал. разве что не надо было заявлять это как цитату.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	88. "Сравнение эффективности разработки интерфейсов с..."	+3 +/–
	Сообщение от Vkni (ok) on 20-Мрт-13, 23:52
	> ну, *по сути* он правильно сказал. разве что не надо было заявлять > это как цитату. Нет. *По сути*, анонимус переврал, как и ты (кстати, слегка отредактировал и последний аноним :-). У ВИЛ утверждается не то, что КАЖДАЯ кухарка может, а что НЕ ТОЛЬКО богатые чиновники могут. Т.е. среди людей, не являющихся богатыми чиновниками есть люди, способные управлять государством. Совершенно не обязательно, что эти люди - кухарки или чернорабочие. Т.е. из цитаты ВИЛ вообще не следует даже, что "хоть одну кухарку можно научить управлять государством", не говоря уж о "КАЖДОЙ кухарке". :-)
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	89. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 00:00
	хм. да, признаю, ступил. пардон.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	85. "Сравнение эффективности разработки интерфейсов с..."	–1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 23:43
	> Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт. Поэтому низкокачественного и глючного быдлокода будет больше.
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

70. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
Сообщение от Аноним (??) on 20-Мрт-13, 22:11
Про отладку ни слова. Это здорово. Можно за пять минут написать на qml и день отлавливать баги. А можно день писать код и 5 минут потратить на отладку.  Имхо, я люблю писать код, а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни слова. Ни средствами IDE,  ни самописными скриптами. Ждем продолжения.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	84. "Сравнение эффективности разработки интерфейсов с использован..."	+/–
	Сообщение от piteri (ok) on 20-Мрт-13, 23:42
	> Про отладку ни слова. Это здорово. Можно за пять минут написать на > qml и день отлавливать баги. А можно день писать код и > 5 минут потратить на отладку.  Имхо, я люблю писать код, > а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни > слова. Ни средствами IDE,  ни самописными скриптами. Ждем продолжения. Если думать когда пишешь код, то можно за пять минут написать код и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	87. "Сравнение эффективности разработки интерфейсов с использован..."	–1 +/–
	Сообщение от Аноним (??) on 20-Мрт-13, 23:44
	> Если думать когда пишешь код, то можно за пять минут написать код > и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны. В теории все просто. На практике когда будет какая-нибудь навороченная, многопоточная, event-driven прога - вы опупеете что с отладкой, что с логами. Особенно когда проблемная ветка кода вызывается только после дождичка в четверг високосного года, например.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	98. "Сравнение эффективности разработки интерфейсов с использован..."	+1 +/–
	Сообщение от Crazy Alex (ok) on 21-Мрт-13, 01:23
	А с логами - это уже не отладка, по вашему? Только если пошагово в дебаггере прыгать? Впрочем, отладку гуя по логам - это, конечно, "гениальное" предложение.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	100. "Сравнение эффективности разработки интерфейсов с..."	+/–
	Сообщение от arisu (ok) on 21-Мрт-13, 01:40
	> Впрочем, отладку гуя по логам — это, конечно, «гениальное» предложение. нормальное вполне. отладчик в принципе неудобен, и не только для этого. в идеале вообще желательно внутри софта иметь командную консоль, откуда можно тормознуться и исследовать/менять состояние софта. ну да, встроеный отладчик получается. а если там ещё и monkey pathcing есть…
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема