URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 89220
[ Назад ]

Исходное сообщение
"Сравнение эффективности разработки интерфейсов с использован..."

Отправлено opennews , 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.me/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.me/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.me/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.me/opennews/art.shtml?num=36446


Содержание

Сообщения в этом обсуждении
"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 13:53 
> QML/JavaScript отмечен как более высокоуровневое средство разработки,

Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага. Тогда как си за такое сразу послал бы на и был бы прав. А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 13:59 
>А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься.

Вам таки нужно больше для создания интерфейса?


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 14:11 
Есть же люди, которые логику приложению реализуют прямо в коде для работы с GUI, а потом месразбираются что они понавоязи.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 14:37 
Это не шуточная проблема, у нас примерно такое и есть, особенно нереально тяжело это  рефакторить. Нужен очень жесткий контроль по использованию js что бы не писали на нем слишком много. а так QML ниче, мне нравится.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 14:55 
> Это не шуточная проблема, у нас примерно такое и есть, особенно нереально
> тяжело это  рефакторить. Нужен очень жесткий контроль по использованию js
> что бы не писали на нем слишком много. а так QML
> ниче, мне нравится.

я смотрю на все эти FirefoxOS, Tizen и прочие, и понимаю, что никакого контроля не получиться


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 14:58 
Я не понимаю как на этом можно сделать что-то сложнее калькулятора.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Anonim , 20-Мрт-13 15:34 
>Я не понимаю как на этом можно сделать что-то сложнее калькулятора.

Вот тут http://www.youtube.com/watch?v=kvWeE3kurEQ люди делятся опытом


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 16:49 
Это не проблема js, это проблема людей.
Чем более высокоуровневый язык - тем легче на нем быдлокодить, откладывая решение проблем с качеством кода на потом.

Многие еще не могут понять сам js, что его парадигма сильно отличается от других ОO-языков, и шпарят на нем так, как они привыкли писать на C++.

И GUI тут тоже ни при чем. На js уже давно можно решать задачи, отвязанные от GUI, и рефакторится он прекрасно. Другое дело, что пока в node.js юные хацкеры сильно косячат, создавая о js неправильное представление. Лучше стандарты CommonJS для начала почитать, прежде чем делать выводы.

Другое дело еще, что сама Qt сильно на GUI завязана, что тоже в свою очередь создает неравильноt впечатление о js.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 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 может быть собран без зависимости от графических подсистем :).


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 23:43 
> Если кто си++ нормально освоил — JS ему вообще будет на один зубок, имхо.

только вот зуб сломается. большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. до финиша редкий кактус долетает.

вообще-то «на один зубок» будет тому, кто знает Scheme (но будет ругаться матом за корявость).


"Сравнение эффективности разработки интерфейсов с..."
Отправлено mma , 21-Мрт-13 15:35 
> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.

тут как бы цель не оправдывает средства, это как в слона дробиной, посмотришь на все это и думаешь ну и зачем это тут в браузере.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:43 
>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.
> тут как бы цель не оправдывает средства, это как в слона дробиной,
> посмотришь на все это и думаешь ну и зачем это тут
> в браузере.

вот-вот. «зачем мне лопата, мне копать надо!» зато незнание не мешает им гордо говорить: «а, жабоскрип… знаю, за пол-часа выучил.» а потом показываешь им простой js-код — и наблюдаешь мёртвое зависание системы. с последующим выходом на арену OOM-киллера и воплями: «да этот ваш js вообще гуано, а не язык!» а знание-то куда-то испаряется.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:45 
>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.
> тут как бы цель не оправдывает средства, это как в слона дробиной,
> посмотришь на все это и думаешь ну и зачем это тут
> в браузере.

p.s. прототипная модель и замыкания, кстати, используются не только в js. даже в новый цпп попытались кусочек последнего протащить (вышло как обычно, правда, но это уже другая сказка).

да и вообще. человек, считающий себя программистом, а не быдлокодером, про эти вещи знает и использовал, когда писал не на си.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено angra , 21-Мрт-13 03:03 
Судя понаписанному, js вы так и не смогли осилить, как в общем-то и C++. Проверка синтаксиса в js есть на стадии "компиляции", проверка типов в основном в рантайме, но я не сказал бы что это сильно усложняет отлов ошибок. А в С++ можно перегружать функции, что замечательно херит преимущества статической типизации, увеличивает вероятность возникновения и затрудняет поиск ошибок.

Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь им все скриптовые языки на один зубок. Они такую херню на скриптовых языках пишут, что рука не покидает лица при просмотре. В доке по перлу для них даже специальные разъяснения добавили, чтобы хоть от самых частых фейлов избавить, но судя по коду, что мне попадается, помогает это слабо.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 03:06 
> Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь
> им все скриптовые языки на один зубок. Они такую херню на
> скриптовых языках пишут, что рука не покидает лица при просмотре.

это да. поскольку они знают только о молотке, то любым инструментом пытаются пользоваться как молотком. получается обычно плохо. что характерно, при этом они не себя винят в том, что неправильно инструмент используют, а инструмент в том, что он не молоток.

очень сильно js этим страдает, кстати. отчего-то многие уверены, что js — это такой простой язык, который и учить-то не надо. а то, что по идеологии он ближе к схеме и смолтолку… фигня, всё равно молотком будет.


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

"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:47 
> эти люди никогда не попадают в ловушки несоответствия концепций и железа

i lol'd hardly.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено jOKer , 21-Мрт-13 07:51 
>А в случае JS сделано все для того чтобы лажа прошла всю мыслимую авотматическую валидацию

Освойте для себя сервис-ориентированные архитектуры, разместите бизнес-логику на (допустим) RESTfull веб-сервисах, оставив на долю js только gui, и будет вам щастье. Много-много щастья.

>Если кто си++ нормально освоил - JS ему вообще будет на один зубок, имхо.

Улыбнул, приятель))) Думаю, что этот свой "зубок" православный си-шник будет оттачивать не один месяц. Да и отточит ли - еще вопрос.

>Да что там, предлагаю новый слоган: Written once. Debug everywhere.
> А в паре мест быдлокодеры вообще написали "бананасы". Но этого тоже никто не заметит.

Внезапно: проблему "бананасов" можно извести почти до нуля грамотно построенным юнит-тестом. А в качестве примера тулкита, в котором отличная долговременная поддержка кода, платформа автоматического тестирования и т. д. можно привести dojo. И, думается мне, что не только его. Просто быдлокодеры этим не парятся и пишут свои поделия на коленке (хых: пожалуй даже на переменке)... ну и результат соответствующий))


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 08:03 
проблемы бананасов сводятся почти к нулю простым линтером. написать который для seasoned c/c++ programmer — пара дней работы. с пивом. однако же Зубры ЦыПыПы больше любят кактусы, поэтому едят. и, конечно, свято уверены, что раз они, Зубры, жрут кактусы — то и все остальные жрут кактусы. ведь не может же так быть, чтобы кто-то был умнее, да прекрасней и милее.

p.s. проще говоря: «некогда за лопатой бегать, копать надо, и так пальцы болят!»


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 14:25 
проблема в том, что орава жабопогромистов ничего более не умеет, но хочет жрат

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 15:02 
> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет
> жрат

проблема в том что C/C++-программисты настолько умные, и настолько много всего держут у себя в голове когда разрабатывают программу [например держут в голове информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами и не забывают опустошать циклические связи между объектами (используя слабые ссылки там где надо, и не используя так где не надо!)]....

....что у них совсем не остаётся времени на продумывание таких банальных вещей как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность этого события. (да! событие пришло в обработчик события! но это НЕ обозначает что нужно его сразу же обрабатывать! вдруг уже позно его обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже успел запустить протеворечивый механизм?)

бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи, а из-за тормозов компьютера или из-за тормозов интернета -- программа не в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае программа не должна продолжать делать то что УЖЕ делать нет нужды.

и таких вот мелочей -- в программах бывает очень много! и программисту первым делом нужно именно обращать внимание НА ЭТО, а не на то насколько красивым выглядит структура того или иного объекта, или насколько канонически верно сделана операция пере-балансировки бинарного дерева.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 15:28 
>> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет
>> жрат
> проблема в том что C/C++-программисты настолько умные, и настолько много всего держут
> у себя в голове когда разрабатывают программу [например держут в голове
> информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами
> и не забывают опустошать циклические связи между объектами (используя слабые ссылки
> там где надо, и не используя так где не надо!)]....

а программисты на жаваскрипте структуру программы в голове не держат? х**к-х**к и в продакшн?

> ....что у них совсем не остаётся времени на продумывание таких банальных вещей
> как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность
> этого события. (да! событие пришло в обработчик события! но это НЕ
> обозначает что нужно его сразу же обрабатывать! вдруг уже позно его
> обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже
> успел запустить протеворечивый механизм?)

вдруг-вдруг-вдруг, не говоря уже о том, что проблема высосана из пальца

> бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи,
> а из-за тормозов компьютера или из-за тормозов интернета -- программа не
> в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае
> программа не должна продолжать делать то что УЖЕ делать нет нужды.

вообще-то мы о десктопе говорим, какой интернет?

> и таких вот мелочей -- в программах бывает очень много! и программисту
> первым делом нужно именно обращать внимание НА ЭТО, а не на
> то насколько красивым выглядит структура того или иного объекта, или насколько
> канонически верно сделана операция пере-балансировки бинарного дерева.

у вас совершенно случайные знания, о том чем занимаются C++ программисты, да и программисты вообще. базвордами типа "бинарное дерево" советую не кидаться, ибо уже видно что вы плаваете в теме


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено тоже Аноним , 20-Мрт-13 16:05 
Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!".
Настоящий юзер-френдли интерфейс, безусловно, должен понимать такие очевидные вещи.
Жаль, что использование тех или иных технологий само по себе таким знанием интерфейс не обогатит.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 16:27 
>Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!".

проблема в том, что интерфейс в результате должен обладать телепатией, чтобы отличить случаи "нужно было 5 раз" и "нужно было 1 раз, но .."
алсо, лично я считаю интерфейс который такое позволяет вредным. он создает армию тупых людей


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено mr. green thumb , 20-Мрт-13 16:46 
вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 16:50 
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои
> розовые очки

это проблема программы? программа должна учитывать, что у пользователя заклинило клавишу, поломалась одна ось вращения мыши и прочее? ок, пишите четко ТЗ, если мы делаем прошивку космического аппарата, ну и платите соответственно


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 17:00 
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки

с какой вероятностью клавишу заклинит у умного человека, и с какой вероятностью заклинит глупого человека, даже если с клавишами у него все в порядке

то что вы мыслите на уровне всегда-никогда, рассуждая про розовые очки, степень ума неплохо характеризует


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено qqq , 20-Мрт-13 17:25 
Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не клиентские приложения

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Vkni , 20-Мрт-13 22:48 
> Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не
> клиентские приложения

Вы не поверите, но это должен разруливать человек, только он может поменять клавиатуру или вычистить замусоренную. :-)


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 20:54 
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои
> розовые очки

а ещё есть вариант «половина клавиатуры не работает! ваша программа говно, не могу половину букв набрать!»

кстати, о забавных багах: если в опере быстро-быстро сделать двойной правоклац на пустом месте страницы, то контекстное меню она покажет, но убрать его кликом «мимо меню» будет нельзя. или esc с клавиатуры, или выбрать действие. такой финт можно провернуть, когда опера над чем-то задумалась и не успела сразу на вызов меню отреагировать.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 23:34 
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки

Ага, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг в руки.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 21-Мрт-13 13:06 
>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
> Ага, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг
> в руки.

Демагогия.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:48 
>>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
>> Ага, «да чтоб у тебя ресет заклинил». Чини это потом программно, флаг
>> в руки.
> Демагогия.

причём началась она с поста «а если клаву заклинит?!»


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 18:42 
> Вам таки нужно больше для создания интерфейса?

А это сильно зависит от интерфейса. Если это интерфейс для дебильника или автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических редакторов или там еще чего посложнее hello world-а - бывают и достаточно нетривиальными.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Led , 21-Мрт-13 02:57 
>> Вам таки нужно больше для создания интерфейса?
> А это сильно зависит от интерфейса. Если это интерфейс для дебильника или
> автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс
> например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических
> редакторов или там еще чего посложнее hello world-а - бывают и
> достаточно нетривиальными.

Например, XUL?


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 03:07 
> Например, XUL?

или так, да — дебильными.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 21-Мрт-13 14:30 
>Вам таки нужно больше для создания интерфейса?

А кто сказал, что JS только  для интерфейса?


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Ы , 20-Мрт-13 14:17 
невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 14:29 
> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка

динамическая типизация - это отличный способ выстрелить себе в ногу или словить "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс строго не задан


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Ы , 20-Мрт-13 14:35 
угу для этого её и придумали, давайте приводить ещё возможности накосячить

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 14:39 
>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
> строго не задан

тоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) ..

говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку" -- особо ничего плохого случиться не может. а вот случай "забыл сконвертировать число в строку" будет сразу заметен в течении 5 минут работы программы.

от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов..


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 14:53 
>тоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) ..

функция требует два аргумента, их тип не задан, это же динамическая типизация

>от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов..

фигасе, "кроме случая". у большинства функций разнородные аргументы вообще-то


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 15:11 
> у большинства функций разнородные аргументы вообще-то

типа как:
    объект, число, число, число
или , например
    объект, число, число
???

по моему это не совсем разнородные :-)

редкий случай когда напимер 3 аргумента и все разнородные


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 15:19 
>> у большинства функций разнородные аргументы вообще-то
> типа как:
>     объект, число, число, число
> или , например
>     объект, число, число
> ???

еще раз, не везде аргументы функции состоят из наборов чисел. более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API)

>редкий случай когда напимер 3 аргумента и все разнородные

далеко не редкий


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено souryogurt , 20-Мрт-13 16:34 
>> более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API)

Почему?


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Пиу , 20-Мрт-13 16:47 
потому что их легко перепутать ;)

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено VoDA , 20-Мрт-13 22:37 
>> у большинства функций разнородные аргументы вообще-то
> типа как:
>     объект, число, число, число
> или , например
>     объект, число, число
> ???
> по моему это не совсем разнородные :-)

Чаще объект, объект, объект. Внутри, конечно, будут числа, но не всегда первым уровнем.

PS еще и список объектов в функцию можно передавать. А уж замыкание так это вообще легко ;)


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 20:58 
> от перепутанных местами параметров — статическая типизация тоже (как и динамическая) не
> защищает кстате..

а вот в Smalltalk это решили очень изящно. и без проверки типов.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено VoDA , 20-Мрт-13 22:43 
>>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
>> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
>> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
>> строго не задан
> тоесть например функция требует объект <Кнопка> , а мы передадим туда объект
> <Временная_Константа>? и как же это может произойти на практике? :-) ..
> говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку"

У меня в практике были косяки типа кодил-кодил - все работало. Зашел на соседний экран - упало. Причем с кривейшей ошибкой.

Довольно долго втыкал и матерился, пока не пошел сплошняком проверять файлы. И оказалось, что рядом с одним из описаний объектов затесался спец-символ (когда переключал экраны кнопку зацепил). То ли . то ли ; и, как следствие, отвалило одно из полей. Но это стало заметно не сразу, а через продолжительный период времени.

Печаль =( Не люблю JS за невозможность провалидировать корректность кода в процессе программирования (до запуска на исполнение).


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 22:49 
тут дело-то в том, что js никогда и не задумывался как язык для разработки большого софта. а теперь его обвешивают костылями и пихают невпихуемое.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено Аноним , 21-Мрт-13 13:07 
> тут дело-то в том, что js никогда и не задумывался как язык
> для разработки большого софта. а теперь его обвешивают костылями и пихают
> невпих/емое.

Ничего не напоминает?


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:41 
>> тут дело-то в том, что js никогда и не задумывался как язык
>> для разработки большого софта. а теперь его обвешивают костылями и пихают
>> невпих/емое.
> Ничего не напоминает?

много всякого напоминает. но беседа-то у нас про js.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено piteri , 20-Мрт-13 23:29 
>и как же это может произойти на практике?

Легко
>будет сразу заметен в течении 5 минут работы программы.

После установки заказчику.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено jOKer , 21-Мрт-13 08:07 
>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
> строго не задан

Давайте все-таки не путать динамическую/статическую типизацию и строгую/мягкую типизацию. Внезапно: есть ЯП в которых реализована строгая динамическая типизация. И в этих ЯП автоматического приведения к типу нет, а вот замыкания, инжекция кода и прочие вкусняшки, - напротив, имеются.

ЗЫ. А "борцам" с динамической типизацией из-за того, что у них автоматически привелись типы, а они это прощелкали, надо выстрелить не в ногу, а в голову - все равно она им не к чему.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 08:14 
отчасти-то он прав. потому что новоявленые МегаГуру про контракты, может, и слышали, но в виду отсутствия мозга ничего не поняли. соответственно, хвалёные библиотеки часто вместо контрактов светят половым гениталием. это ж «тормозит» и вообще «лишний код».

с другой стороны — за отсутствие булевого типа и использование «+» для соединения строк таки надо было бы лишить обеда. и ужина.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 17:10 
А в каких языках динамическая типизация НЕ ВОЗМОЖНА?

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено exist , 20-Мрт-13 18:15 
Видимо, в языках со строгой типизацией. Например, Ada.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 21-Мрт-13 12:12 
Мягкое и теплое, ага. В Python динамическая строгая типизация.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 17:56 
> Мягкое и теплое, ага. В Python динамическая строгая типизация.

хорошая шутка.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Аноним , 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
>>>


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 22-Мрт-13 16:13 
a = «fuck»;
a = 40;
print a+2;

опа. это — не строгая типизация. какого хрена у 'a' — разные типы во время выполнения программы?

да, строгой без статики — увы. смиритесь.

впрочем, вколачивать ум в черепа любителям гвидобейсика — занятие неблагодарное. поэтому удаляюсь, бисера жаль.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 18:43 
> ВОЗМОЖНОСТЬ динамической типизации это плюс языка

Только если ее делать не через опу. Т.е. с возможностью форсануть статическую для уменьшения грабель. А тут мало того что типизация динамическая, так еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект потом замахаешься дебажить в поисках опечатки.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 22-Мрт-13 14:32 
>> ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> Только если ее делать не через опу. Т.е. с возможностью форсануть статическую
> для уменьшения грабель. А тут мало того что типизация динамическая, так
> еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки
> кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект
> потом замахаешься дебажить в поисках опечатки.

Приведите пример крупного проекта по созданию интерфеса программы.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 14:20 
> JS создал на автомате...

как это он создал на автомате? кто ему разрешил самодеятельность? или мы рассматриваем случай когда программист забыл добавить 'use strict' в начало файла?


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 14:25 
> ...си за такое сразу послал бы...

анализатор статической типизпции -- не сделает за программиста его работу.

если ты написал (по ошибке)

memset(my_obj_ptr, 0, sizeof(my_obj_ptr));
вместо
memset(my_obj_ptr, 0, sizeof(*my_obj_ptr));

то компилятор тебя не пошлёт (и темболее "сразу").

иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки.

однако статическая компиляция не палочка-выручалочка. по большей части она в основном только указывает на то что "чувак, ты хочешь же вывести на экран строку, а передаёшь в параметре число... ну забыл сконвертировать же!", а не на какую-то серъёзную штуку, которая годами может себя не проявлять.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено qux , 20-Мрт-13 17:18 
> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки.

Некоторые не знаю, а в общем, как и все прочие, страдают забиванием. Сравнить, например, кол-во полезных подсказок, выдаваемых gcc на не-helloworld по дефолту и с -Wall -Wextra (-pedantic --std=c99 -Werror). А потом кол-во проектов, которые ближе ко второму. Особенно коммерческих.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Алексей Морозов , 20-Мрт-13 18:52 
> memset(my_obj_ptr, 0, sizeof(my_obj_ptr));

Ну, вот конкретно такое достаточно хорошо ловится юниттестами, запущенными под валгриндом


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Vkni , 20-Мрт-13 22:46 
> анализатор статической типизпции -- не сделает за программиста его работу.

Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор и динамическое типизирование.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 22:51 
>> анализатор статической типизпции — не сделает за программиста его работу.
> Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор
> и динамическое типизирование.

не соглашусь. другое дело, что в js нет встроеного механизма указать типы, если надо. зато есть идиотия с использованием одного и того же оператора для сложения строк и чисел.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Vkni , 21-Мрт-13 00:02 
> не соглашусь. другое дело, что в js нет встроеного механизма указать типы,
> если надо. зато есть идиотия с использованием одного и того же
> оператора для сложения строк и чисел.

Сравни OCaml и JS: в первом система статических типов, вывод типов методом ХМ (т.е. указывать тип можно, но не обязательно - он будет выведен), именованные параметры, значения параметров по-умолчанию. Единственная фигня - операторы для вещественных чисел /., *., +. и -., хотя никто не мешал перегрузить. Это, впрочем, исправлено в F#.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 00:16 
> Сравни OCaml и JS

я окамла не знаю, увы. ну, так — на уровне «о! окамл! я не испуган, но озадачен.»

впрочем, сравнение всё равно некорректно: всё-таки js изначально не планировался как язык для написания чего-то сложнее, чем небольшие скриптики. в actionscript это попытались починить, но зачем-то притащили и симула-подобную (точнее, цпп-подобную) объектную модель.

(да, я знаю, что дефис не нужен; но с ним красивей)

беда js в том, что никто изначально не предполагал масштабов бедствия. а в итоге современные реализации js, например, должны бережно повторять глюки оригинального дизайна. с var, например, у которого scope — вся функция, а не блок. или с тем, что eval (который и так-то не особо нужен, но…), присвоеная переменной — уже не совсем та же самая eval.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Vkni , 21-Мрт-13 00:32 
> я окамла не знаю, увы. ну, так — на уровне «о! окамл!
> я не испуган, но озадачен.»

Посмотри, не пожалеешь - штука маленькая, быстрая и очень удобная. Учебник по OCaml - http://caml.inria.fr/pub/docs/oreilly-book/ (где-то есть перевод на русский). Сочетает императивщину и функциональщину. И его идеи - более-менее передний край CS, как говорят специалисты, в 90-е научное развитие языковых средств остановилось (а индустрия это постепенно подсасывает).

После этого будет тяжко смотреть на С++ с его шаблонами и смешно на тутошние языковые споры.

> беда js в том, что никто изначально не предполагал масштабов бедствия.

Есть ещё чудесный PHP. :-)


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 00:49 
>> я окамла не знаю, увы.
> Посмотри, не пожалеешь — штука маленькая, быстрая и очень удобная.

да я знаю это — теоретически. а на практике как-то всё лениво, каждый раз на завтра откладываю.

> где-то есть перевод на русский

это не обязательно. %-)

> После этого будет тяжко смотреть на С++ с его шаблонами

да мне давно смешно.

> и смешно на тутошние языковые споры.

и так… собственно, после Scheme, где спокойно сочетается императивщина, функциональщина, разные объектные модели и pattern matching… разве только системы типов нет, хотя type inference поверх компилятора повесить несложно, code as data же.

>> беда js в том, что никто изначально не предполагал масштабов бедствия.
> Есть ещё чудесный PHP. :-)

нененене. на js всё-таки можно писать, хоть и с трудом. но есть замыкания, лямбды и прочие приятные вещи. а у php одни костыли из каждой дырки и 100500 функций в global namespace. %-)


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Crazy Alex , 21-Мрт-13 01:11 
В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к одному.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 01:14 
> В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к
> одному.

да у них у всех ноги из одного места растут.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 22:50 
> если ты написал (по ошибке)
> memset(my_obj_ptr, 0, sizeof(my_obj_ptr));
> вместо
> memset(my_obj_ptr, 0, sizeof(*my_obj_ptr));

Во-первых, где здесь статическая типизация? Перепутана константа. Во-вторых, некоторые компиляторы выдают warning при компиляции такого (в gcc, вроде, было).


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Vkni , 21-Мрт-13 00:05 
> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием
> из-за того что думают будто компилятор находит все их ошибки.

С момента изобретения С прошло уже 40 лет, пора бы и на другие языки посмотреть. В частности, на ML/Haskell и подобные - там значительно более серьёзная система типов, нежели в С. И результаты работы анализатора типов, разумеется, тоже более серьёзные.

Он тоже не найдёт все ошибки, но результат явно будет лучше, чем в С, где можно поменять в memset 2 последних параметра местами и это пройдёт.


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

"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 01:35 
не хватает только стандарта и нескольких компиляторов. кагбэ D1 уже нет, а D2 ещё толком нет. и нераспространено. но в остальном — надеюсь, что он в конце концов вытолкает цпп на обочину истории и легаси-кода.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено TbIK , 21-Мрт-13 19:03 
> не хватает только ....

Немного не так: кто ХОЧЕТ писать - тому всего хватает. Кто не хочет - тому ВЕЧНО чего-то нехватает, "мешается в танце" и т.п.

> D2 ещё толком нет.

Есть. Работающий компилятор, бери, да пользуйся!

> и нераспространено.

Как и любой язык без тонны говномаркетинга и бабла. Но при наличии разумных прогеров, легко вольётся в ряды. Вы же про него уже знаете! Я несколько перделок написал. Другие тоже не останутся в стороне, сравнив его с сипипями и цэшарпами.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 19:25 
>> не хватает только ….
> Немного не так: кто ХОЧЕТ писать — тому всего хватает. Кто не
> хочет — тому ВЕЧНО чего-то нехватает, «мешается в танце» и т.п.

если ты пишешь себе приветмиры — то не вопрос, хоть для кнутовой шестибитовой машины пиши.

>> D2 ещё толком нет.
> Есть. Работающий компилятор, бери, да пользуйся!

«есть» — это когда есть хотя бы две равноценные реализации и документ, на котором они базируются.

>> и нераспространено.
> Как и любой язык без тонны говномаркетинга и бабла.

в си очень много вливали, да. и рекламировали на каждом углу.

> Но при наличии разумных прогеров, легко вольётся в ряды.

в качестве тестера — натурально. ничего плохого в этом нет, но мне неинтересно.

> Вы же про него уже знаете!

я про него знаю ещё с тех пор, как Уолтер его только сочинял.

> Я несколько перделок написал. Другие тоже не останутся в стороне,
> сравнив его с сипипями и цэшарпами.

вот когда «не останутся» — тогда и стоит рассматривать в качестве языка для будущего проекта. а пока что вероятность подключения энтузиастов к проекту на c/c++ намного больше, чем та же вероятность для проекта на D. как минимум в силу того, что последних сильно меньше.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 19:27 
p.s. вообще, *лично для меня* язык подобного плана стоит более-менее серьёзно рассматривать тогда, когда в стандартном наборе gcc появится компилятор для этого языка.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Led , 21-Мрт-13 03:10 
>> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием
>> из-за того что думают будто компилятор находит все их ошибки.
> С момента изобретения С прошло уже 40 лет, пора бы и на
> другие языки посмотреть. В частности, на ML/Haskell и подобные - там
> значительно более серьёзная система типов, нежели в С.

А разве в C есть что-то кроме char, int и float? Других типов нет - только "модификаторы" для указанных. Назвать это "системой типов"... мягко говоря, смешно.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 03:13 
> А разве в C есть что-то кроме char, int и float?

да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что не надо уж совсем старичка унижать, он местами ещё вполне ничего.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Led , 21-Мрт-13 03:21 
>> А разве в C есть что-то кроме char, int и float?
> да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что
> не надо уж совсем старичка унижать, он местами ещё вполне ничего.

Никто его и не унижает. Но и превозносить его как божественное откровение и идеал - не стОит.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 03:31 
> Никто его и не унижает. Но и превозносить его как божественное откровение
> и идеал — не стОит.

но в нише «переносимый макроассемблер» у него таки конкурентов нет.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Vkni , 21-Мрт-13 04:45 
> но в нише «переносимый макроассемблер» у него таки конкурентов нет.

Вообще, можно было бы и улучшить косметически - сделать вывод типов, убрать неявные преобразования. А так - да, ассемблер.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 06:05 
нененене, не надо. а то мне будет скучно на нём писать. ;-)

"Сравнение эффективности разработки интерфейсов с..."
Отправлено Led , 21-Мрт-13 06:58 
>> Никто его и не унижает. Но и превозносить его как божественное откровение
>> и идеал — не стОит.
> но в нише «переносимый макроассемблер» у него таки конкурентов нет.

Нет. К сожалению.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 15:38 
>Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага.

Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт... да хоть на Фортране!


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено qux , 20-Мрт-13 17:19 
Тогда уже гуй на вебе, портабельности ради.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 18:44 
> Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт...

А чем глюки в гуе лучше глюков в счете?


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено qux , 20-Мрт-13 19:11 
Очевидно, при глюках в гуе иногда можно взять другой, или CLI-вариант, над которым был гуй.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено ВовкаОсиист , 20-Мрт-13 16:10 
Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю программу на js. Хотя всем наплевать, все побежали быстро все переписывать на js, qml-же!

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 22-Мрт-13 19:59 
> Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и
> в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю
> программу на js. Хотя всем наплевать, все побежали быстро все переписывать
> на js, qml-же!

Ну и как на xml подстветить неправильно заполенные поля при вводе?


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 22-Мрт-13 20:19 
> Ну и как на xml подстветить неправильно заполенные поля при вводе?

точно так же, как и без него. тот, кто делает валидатор исключительно средствами GUI и его языка — идиот. а в нормальном случае всё равно понадобится механизм, при помощи которого основная софтина будет отмечать такие поля.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено CR , 20-Мрт-13 17:28 
> через полчаса счета

Какого еще "счета"?

QML/JavaScript предназначены для создания GUI. "Счет" пиштеся как обычно - на C/C++.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Xasd , 20-Мрт-13 14:16 
> Сравнение охватывает такие вопросы, как удобство разработки, оценка трудозатрат, компактность кода, потребление памяти в процессе работы, скоросоть запуска, производительность итоговых приложений, визуальная привлекательность и т.п. Для оценки использовался Капитан Очевидность

fixed :)


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 14:17 
А почему QML, а не чистый Qt?

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Anonymus.UA , 20-Мрт-13 14:25 
Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям...

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено anonymous , 20-Мрт-13 19:54 
>Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям...

Где ты увидел в Qt чистый си? Развелось тут неучей, понимаешь.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Mihail Zenkov , 20-Мрт-13 15:19 
Их саперы занимают памяти больше, чем ядро :(

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 18:46 
> Их саперы занимают памяти больше, чем ядро :(

Ну так ядро писали нормальные системщики, на сях, без халтуры. А это апликушники. Раздолбаи и пофигисты. Которых хлебом не корми, дай только индусский код понаписать.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено ВовкаОсиист , 20-Мрт-13 16:15 
Я правильно понимаю, что они сравнили императивный стиль программирования с декларативным? Или JS с Си? Тогда реквестирую сравнение Qt-C++ vs QML+js.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено mr. green thumb , 20-Мрт-13 16:53 
подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс или можно в свободное время?



"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Michael Shigorin , 20-Мрт-13 18:00 
> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс

Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 21-Мрт-13 13:11 
>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс
> Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...

Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище....


"(offtopic) microsoft student partners are NOT welcome"
Отправлено Michael Shigorin , 21-Мрт-13 15:15 
>>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс
>> Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...
> Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище....

Паства тут ни при чём, поскольку вопрос технический, а не духовный (и я сам паства).  А с коллегами тут единодушен -- вещатели "правды", в том числе Вы лично, и тем более дешёвой рекламы MS -- здесь невостребованы вместе со своим (если вообще своим) мнением.  Научитесь _слышать_, а не только вещать -- приходите.

Сколько раз это надо повторить, чтобы дошло?

PS: слово "правда" забрано в кавычки потому, что выставляете как правду либо неправду, либо смесь правды с ложью; либо недоговариваете.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 18:40 
>>При этом различия в производительности и потреблении ресурсов оказались не такими заметными как можно было предположить.

А вес фрэймворка интересно сравним?


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 20:48 
очень ценное сравнение от человека, который:
«Please note these are only my guesses — guesses of developer neither much experienced in plain C nor in EFL.»

в принципе, дальше и разбирать неинтересно.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено skybon , 20-Мрт-13 21:19 
Бенчмарк может произвести и непрограммист.

Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 21:31 
> Бенчмарк может произвести и непрограммист.

ага. а домоходяйка — управлять государством.

> Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть
> — факт.

это не факт, это теория. то, что яростные обличители и находители простоты не знают, как работает Edje и Embryo, и как создаются интерфейсы в EFL — даже не удивительно. удивительно было бы, если бы знали.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Аноним , 20-Мрт-13 22:01 
офтоп

> ага. а домоходяйка — управлять государством.

Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно.

а по теме - сравнивать довольно небольшой набор C библиотек и огромный плюснутый qt/qml - бред. еще больший бред кодить интерфейсы на C. Гр. интерфейс по своей природе декларативен. и стараться писать его в 21 веке надо в чём угодно, только не в императивных языках.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 22:23 
> Видимо удобно.

ну, гейтсу же приписывают высказывание про 640 кб. пусть и ленин пострадает.

> а по теме — сравнивать довольно небольшой набор C библиотек и огромный
> плюснутый qt/qml — бред.

сравнивали удобство создания морды как раз, и сопряжения её с логикой. тут как раз всё более-менее нормально.

> еще больший бред кодить интерфейсы на C.

именно поэтому в EFL так делают только любители Elementary. для Edje морда делается на Embryo и описывается местами похоже на qml. там внутри почти pawn есть, специально для всяких нестандартных переходов и анимашек. но можно и без него, получается всё равно симпатично. конечно, морду можно заменять, вплоть до вообще переделать.

> Гр. интерфейс по своей природе декларативен.

ровно до тех пор, пока декларации поддерживают хотелки. как только хотелки выходят за рамки — начинается разного рода битьё в бубен.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено Аноним. , 20-Мрт-13 22:58 
>Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно.

Тогда уж будьте добры сами цитировать правильно и не придумывать не существующих концов.

"Мы не утописты. Мы знаем, что любой чернорабочий и любая кухарка не способны сейчас вступить в управление государством. Но мы требуем немедленного разрыва с тем предрассудком, будто управлять государством, нести будничную, ежедневную работу управления в состоянии только богатые или из богатых семей взятые чиновники."

«Удержат ли большевики государственную власть?» 1917.


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 20-Мрт-13 23:26 
ну, *по сути* он правильно сказал. разве что не надо было заявлять это как цитату.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено Vkni , 20-Мрт-13 23:52 
> ну, *по сути* он правильно сказал. разве что не надо было заявлять
> это как цитату.

Нет. *По сути*, анонимус переврал, как и ты (кстати, слегка отредактировал и последний аноним :-). У ВИЛ утверждается не то, что КАЖДАЯ кухарка может, а что НЕ ТОЛЬКО богатые чиновники могут. Т.е. среди людей, не являющихся богатыми чиновниками есть люди, способные управлять государством. Совершенно не обязательно, что эти люди - кухарки или чернорабочие.

Т.е. из цитаты ВИЛ вообще не следует даже, что "хоть одну кухарку можно научить управлять государством", не говоря уж о "КАЖДОЙ кухарке". :-)


"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 00:00 
хм. да, признаю, ступил. пардон.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено Аноним , 20-Мрт-13 23:43 
> Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт.

Поэтому низкокачественного и глючного быдлокода будет больше.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 22:11 
Про отладку ни слова. Это здорово. Можно за пять минут написать на qml и день отлавливать баги. А можно день писать код и 5 минут потратить на отладку.  Имхо, я люблю писать код, а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни слова. Ни средствами IDE,  ни самописными скриптами. Ждем продолжения.

"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено piteri , 20-Мрт-13 23:42 
> Про отладку ни слова. Это здорово. Можно за пять минут написать на
> qml и день отлавливать баги. А можно день писать код и
> 5 минут потратить на отладку.  Имхо, я люблю писать код,
> а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни
> слова. Ни средствами IDE,  ни самописными скриптами. Ждем продолжения.

Если думать когда пишешь код, то можно за пять минут написать код и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Аноним , 20-Мрт-13 23:44 
> Если думать когда пишешь код, то можно за пять минут написать код
> и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны.

В теории все просто. На практике когда будет какая-нибудь навороченная, многопоточная, event-driven прога - вы опупеете что с отладкой, что с логами. Особенно когда проблемная ветка кода вызывается только после дождичка в четверг високосного года, например.


"Сравнение эффективности разработки интерфейсов с использован..."
Отправлено Crazy Alex , 21-Мрт-13 01:23 
А с логами - это уже не отладка, по вашему? Только если пошагово в дебаггере прыгать? Впрочем, отладку гуя по логам - это, конечно, "гениальное" предложение.

"Сравнение эффективности разработки интерфейсов с..."
Отправлено arisu , 21-Мрт-13 01:40 
> Впрочем, отладку гуя по логам — это, конечно, «гениальное» предложение.

нормальное вполне. отладчик в принципе неудобен, и не только для этого. в идеале вообще желательно внутри софта иметь командную консоль, откуда можно тормознуться и исследовать/менять состояние софта. ну да, встроеный отладчик получается. а если там ещё и monkey pathcing есть…