Опубликованы (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.ru/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.ru/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.ru/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.ru/opennews/art.shtml?num=36446
> QML/JavaScript отмечен как более высокоуровневое средство разработки,Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага. Тогда как си за такое сразу послал бы на и был бы прав. А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься.
>А так то да, пока программа на 600 или 1400 строчек - в трех соснах фиг заблудишься.Вам таки нужно больше для создания интерфейса?
Есть же люди, которые логику приложению реализуют прямо в коде для работы с GUI, а потом месразбираются что они понавоязи.
Это не шуточная проблема, у нас примерно такое и есть, особенно нереально тяжело это рефакторить. Нужен очень жесткий контроль по использованию js что бы не писали на нем слишком много. а так QML ниче, мне нравится.
> Это не шуточная проблема, у нас примерно такое и есть, особенно нереально
> тяжело это рефакторить. Нужен очень жесткий контроль по использованию js
> что бы не писали на нем слишком много. а так QML
> ниче, мне нравится.я смотрю на все эти FirefoxOS, Tizen и прочие, и понимаю, что никакого контроля не получиться
Я не понимаю как на этом можно сделать что-то сложнее калькулятора.
>Я не понимаю как на этом можно сделать что-то сложнее калькулятора.Вот тут http://www.youtube.com/watch?v=kvWeE3kurEQ люди делятся опытом
Это не проблема js, это проблема людей.
Чем более высокоуровневый язык - тем легче на нем быдлокодить, откладывая решение проблем с качеством кода на потом.Многие еще не могут понять сам js, что его парадигма сильно отличается от других ОO-языков, и шпарят на нем так, как они привыкли писать на C++.
И GUI тут тоже ни при чем. На js уже давно можно решать задачи, отвязанные от GUI, и рефакторится он прекрасно. Другое дело, что пока в node.js юные хацкеры сильно косячат, создавая о js неправильное представление. Лучше стандарты CommonJS для начала почитать, прежде чем делать выводы.
Другое дело еще, что сама Qt сильно на GUI завязана, что тоже в свою очередь создает неравильноt впечатление о js.
> Это не проблема 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 может быть собран без зависимости от графических подсистем :).
> Если кто си++ нормально освоил — JS ему вообще будет на один зубок, имхо.только вот зуб сломается. большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий. до финиша редкий кактус долетает.
вообще-то «на один зубок» будет тому, кто знает Scheme (но будет ругаться матом за корявость).
> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.тут как бы цель не оправдывает средства, это как в слона дробиной, посмотришь на все это и думаешь ну и зачем это тут в браузере.
>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.
> тут как бы цель не оправдывает средства, это как в слона дробиной,
> посмотришь на все это и думаешь ну и зачем это тут
> в браузере.вот-вот. «зачем мне лопата, мне копать надо!» зато незнание не мешает им гордо говорить: «а, жабоскрип… знаю, за пол-часа выучил.» а потом показываешь им простой js-код — и наблюдаешь мёртвое зависание системы. с последующим выходом на арену OOM-киллера и воплями: «да этот ваш js вообще гуано, а не язык!» а знание-то куда-то испаряется.
>> большинство ломается на стадии прототипной объектной модели. ещё некоторые — на стадии замыканий.
> тут как бы цель не оправдывает средства, это как в слона дробиной,
> посмотришь на все это и думаешь ну и зачем это тут
> в браузере.p.s. прототипная модель и замыкания, кстати, используются не только в js. даже в новый цпп попытались кусочек последнего протащить (вышло как обычно, правда, но это уже другая сказка).
да и вообще. человек, считающий себя программистом, а не быдлокодером, про эти вещи знает и использовал, когда писал не на си.
Судя понаписанному, js вы так и не смогли осилить, как в общем-то и C++. Проверка синтаксиса в js есть на стадии "компиляции", проверка типов в основном в рантайме, но я не сказал бы что это сильно усложняет отлов ошибок. А в С++ можно перегружать функции, что замечательно херит преимущества статической типизации, увеличивает вероятность возникновения и затрудняет поиск ошибок.Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь им все скриптовые языки на один зубок. Они такую херню на скриптовых языках пишут, что рука не покидает лица при просмотре. В доке по перлу для них даже специальные разъяснения добавили, чтобы хоть от самых частых фейлов избавить, но судя по коду, что мне попадается, помогает это слабо.
> Вообще я насмотрелся на код дурачков, выучивших С/С++ и думающих, что теперь
> им все скриптовые языки на один зубок. Они такую херню на
> скриптовых языках пишут, что рука не покидает лица при просмотре.это да. поскольку они знают только о молотке, то любым инструментом пытаются пользоваться как молотком. получается обычно плохо. что характерно, при этом они не себя винят в том, что неправильно инструмент используют, а инструмент в том, что он не молоток.
очень сильно js этим страдает, кстати. отчего-то многие уверены, что js — это такой простой язык, который и учить-то не надо. а то, что по идеологии он ближе к схеме и смолтолку… фигня, всё равно молотком будет.
В защиту си/сипиписников (коим я был лет 20 назад), скажу: зато эти люди никогда не попадают в ловушки несоответствия концепций и железа (что встречается сплошь и рядом). Жабоскрипт прячет кучу деталей под себя и у вновь обученных создаёт ложное ощущение простоты и быстроты кодинга. Тем более это опасно для новичков, не прошедших "школу ассемблера" - у них в голове расхлябаная концепция "чо хочу - то ворочу". Надо быть очень маститым прогером вообще, прежде чем его можно допускать до жабоскриптовых вольностей. Это сродни ЛИСПу в мире ООП: можно столько всего наворотить, что впору одевать каждому смирительную рубашку, дабы эти "навороты" не опрокинули потом какой-нть "интыпрайз".
> эти люди никогда не попадают в ловушки несоответствия концепций и железаi lol'd hardly.
>А в случае JS сделано все для того чтобы лажа прошла всю мыслимую авотматическую валидациюОсвойте для себя сервис-ориентированные архитектуры, разместите бизнес-логику на (допустим) RESTfull веб-сервисах, оставив на долю js только gui, и будет вам щастье. Много-много щастья.
>Если кто си++ нормально освоил - JS ему вообще будет на один зубок, имхо.
Улыбнул, приятель))) Думаю, что этот свой "зубок" православный си-шник будет оттачивать не один месяц. Да и отточит ли - еще вопрос.
>Да что там, предлагаю новый слоган: Written once. Debug everywhere.
> А в паре мест быдлокодеры вообще написали "бананасы". Но этого тоже никто не заметит.Внезапно: проблему "бананасов" можно извести почти до нуля грамотно построенным юнит-тестом. А в качестве примера тулкита, в котором отличная долговременная поддержка кода, платформа автоматического тестирования и т. д. можно привести dojo. И, думается мне, что не только его. Просто быдлокодеры этим не парятся и пишут свои поделия на коленке (хых: пожалуй даже на переменке)... ну и результат соответствующий))
проблемы бананасов сводятся почти к нулю простым линтером. написать который для seasoned c/c++ programmer — пара дней работы. с пивом. однако же Зубры ЦыПыПы больше любят кактусы, поэтому едят. и, конечно, свято уверены, что раз они, Зубры, жрут кактусы — то и все остальные жрут кактусы. ведь не может же так быть, чтобы кто-то был умнее, да прекрасней и милее.p.s. проще говоря: «некогда за лопатой бегать, копать надо, и так пальцы болят!»
проблема в том, что орава жабопогромистов ничего более не умеет, но хочет жрат
> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет
> жратпроблема в том что C/C++-программисты настолько умные, и настолько много всего держут у себя в голове когда разрабатывают программу [например держут в голове информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами и не забывают опустошать циклические связи между объектами (используя слабые ссылки там где надо, и не используя так где не надо!)]....
....что у них совсем не остаётся времени на продумывание таких банальных вещей как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность этого события. (да! событие пришло в обработчик события! но это НЕ обозначает что нужно его сразу же обрабатывать! вдруг уже позно его обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже успел запустить протеворечивый механизм?)
бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи, а из-за тормозов компьютера или из-за тормозов интернета -- программа не в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае программа не должна продолжать делать то что УЖЕ делать нет нужды.
и таких вот мелочей -- в программах бывает очень много! и программисту первым делом нужно именно обращать внимание НА ЭТО, а не на то насколько красивым выглядит структура того или иного объекта, или насколько канонически верно сделана операция пере-балансировки бинарного дерева.
>> проблема в том, что орава жабопогромистов ничего более не умеет, но хочет
>> жрат
> проблема в том что C/C++-программисты настолько умные, и настолько много всего держут
> у себя в голове когда разрабатывают программу [например держут в голове
> информацию об многочисленных структурах/интерфейсах, информацию об управлении ресурсами
> и не забывают опустошать циклические связи между объектами (используя слабые ссылки
> там где надо, и не используя так где не надо!)]....а программисты на жаваскрипте структуру программы в голове не держат? х**к-х**к и в продакшн?
> ....что у них совсем не остаётся времени на продумывание таких банальных вещей
> как [например], при получении входящего события ВАЖНО [каждый раз!] проверять актуальность
> этого события. (да! событие пришло в обработчик события! но это НЕ
> обозначает что нужно его сразу же обрабатывать! вдруг уже позно его
> обрабатывать? вдруг пользователю уже это не нужно так как пользователь уже
> успел запустить протеворечивый механизм?)вдруг-вдруг-вдруг, не говоря уже о том, что проблема высосана из пальца
> бывает так что пользователь делает сразу (почти одновременно) две протеворечивые вещи,
> а из-за тормозов компьютера или из-за тормозов интернета -- программа не
> в состоянии предотвратить осуществление одновременно обоих действий. и в этом случае
> программа не должна продолжать делать то что УЖЕ делать нет нужды.вообще-то мы о десктопе говорим, какой интернет?
> и таких вот мелочей -- в программах бывает очень много! и программисту
> первым делом нужно именно обращать внимание НА ЭТО, а не на
> то насколько красивым выглядит структура того или иного объекта, или насколько
> канонически верно сделана операция пере-балансировки бинарного дерева.у вас совершенно случайные знания, о том чем занимаются C++ программисты, да и программисты вообще. базвордами типа "бинарное дерево" советую не кидаться, ибо уже видно что вы плаваете в теме
Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!".
Настоящий юзер-френдли интерфейс, безусловно, должен понимать такие очевидные вещи.
Жаль, что использование тех или иных технологий само по себе таким знанием интерфейс не обогатит.
>Между прочим, этот господин довольно точно описал логику "Я нажала пять раз не потому, что мне нужно было пять раз, а для убедительности!".проблема в том, что интерфейс в результате должен обладать телепатией, чтобы отличить случаи "нужно было 5 раз" и "нужно было 1 раз, но .."
алсо, лично я считаю интерфейс который такое позволяет вредным. он создает армию тупых людей
вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои
> розовые очкиэто проблема программы? программа должна учитывать, что у пользователя заклинило клавишу, поломалась одна ось вращения мыши и прочее? ок, пишите четко ТЗ, если мы делаем прошивку космического аппарата, ну и платите соответственно
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очкис какой вероятностью клавишу заклинит у умного человека, и с какой вероятностью заклинит глупого человека, даже если с клавишами у него все в порядке
то что вы мыслите на уровне всегда-никогда, рассуждая про розовые очки, степень ума неплохо характеризует
Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не клиентские приложения
> Даже если действительно заклинило клавишу, эту проблему должна разруливать ОС а не
> клиентские приложенияВы не поверите, но это должен разруливать человек, только он может поменять клавиатуру или вычистить замусоренную. :-)
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои
> розовые очкиа ещё есть вариант «половина клавиатуры не работает! ваша программа говно, не могу половину букв набрать!»
кстати, о забавных багах: если в опере быстро-быстро сделать двойной правоклац на пустом месте страницы, то контекстное меню она покажет, но убрать его кликом «мимо меню» будет нельзя. или esc с клавиатуры, или выбрать действие. такой финт можно провернуть, когда опера над чем-то задумалась и не успела сразу на вызов меню отреагировать.
> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очкиАга, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг в руки.
>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
> Ага, "да чтоб у тебя ресет заклинил". Чини это потом программно, флаг
> в руки.Демагогия.
>>> вариант «заклинило клавишу» никогда не происходил у умных людей? снимай свои розовые очки
>> Ага, «да чтоб у тебя ресет заклинил». Чини это потом программно, флаг
>> в руки.
> Демагогия.причём началась она с поста «а если клаву заклинит?!»
> Вам таки нужно больше для создания интерфейса?А это сильно зависит от интерфейса. Если это интерфейс для дебильника или автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических редакторов или там еще чего посложнее hello world-а - бывают и достаточно нетривиальными.
>> Вам таки нужно больше для создания интерфейса?
> А это сильно зависит от интерфейса. Если это интерфейс для дебильника или
> автомата оплаты, с тремя кнопками - оно конечно. А вот интерфейс
> например офисного пакета, кад-образного софта, пакетов 3D моделирования, графических
> редакторов или там еще чего посложнее hello world-а - бывают и
> достаточно нетривиальными.Например, XUL?
> Например, XUL?или так, да — дебильными.
>Вам таки нужно больше для создания интерфейса?А кто сказал, что JS только для интерфейса?
невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языкадинамическая типизация - это отличный способ выстрелить себе в ногу или словить "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс строго не задан
угу для этого её и придумали, давайте приводить ещё возможности накосячить
>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
> строго не задантоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) ..
говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку" -- особо ничего плохого случиться не может. а вот случай "забыл сконвертировать число в строку" будет сразу заметен в течении 5 минут работы программы.
от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов..
>тоесть например функция требует объект <Кнопка> , а мы передадим туда объект <Временная_Константа>? и как же это может произойти на практике? :-) ..функция требует два аргумента, их тип не задан, это же динамическая типизация
>от перепутанных местами параметров -- статическая типизация тоже (как и динамическая) не защищает кстате.. кроме как от случая когда функция принемает несколько параметров которые все являются представителями разных интерфейсов..
фигасе, "кроме случая". у большинства функций разнородные аргументы вообще-то
> у большинства функций разнородные аргументы вообще-тотипа как:
объект, число, число, число
или , например
объект, число, число
???по моему это не совсем разнородные :-)
редкий случай когда напимер 3 аргумента и все разнородные
>> у большинства функций разнородные аргументы вообще-то
> типа как:
> объект, число, число, число
> или , например
> объект, число, число
> ???еще раз, не везде аргументы функции состоят из наборов чисел. более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API)
>редкий случай когда напимер 3 аргумента и все разнородные
далеко не редкий
>> более того, функции у которых на входе много числовых аргументов - плохие функции (в качестве API)Почему?
потому что их легко перепутать ;)
>> у большинства функций разнородные аргументы вообще-то
> типа как:
> объект, число, число, число
> или , например
> объект, число, число
> ???
> по моему это не совсем разнородные :-)Чаще объект, объект, объект. Внутри, конечно, будут числа, но не всегда первым уровнем.
PS еще и список объектов в функцию можно передавать. А уж замыкание так это вообще легко ;)
> от перепутанных местами параметров — статическая типизация тоже (как и динамическая) не
> защищает кстате..а вот в Smalltalk это решили очень изящно. и без проверки типов.
>>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
>> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
>> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
>> строго не задан
> тоесть например функция требует объект <Кнопка> , а мы передадим туда объект
> <Временная_Константа>? и как же это может произойти на практике? :-) ..
> говоря про практику динамической типизации -- кроме как случай "забыл сконвертировать число в строку"У меня в практике были косяки типа кодил-кодил - все работало. Зашел на соседний экран - упало. Причем с кривейшей ошибкой.
Довольно долго втыкал и матерился, пока не пошел сплошняком проверять файлы. И оказалось, что рядом с одним из описаний объектов затесался спец-символ (когда переключал экраны кнопку зацепил). То ли . то ли ; и, как следствие, отвалило одно из полей. Но это стало заметно не сразу, а через продолжительный период времени.
Печаль =( Не люблю JS за невозможность провалидировать корректность кода в процессе программирования (до запуска на исполнение).
тут дело-то в том, что js никогда и не задумывался как язык для разработки большого софта. а теперь его обвешивают костылями и пихают невпихуемое.
> тут дело-то в том, что js никогда и не задумывался как язык
> для разработки большого софта. а теперь его обвешивают костылями и пихают
> невпих/емое.Ничего не напоминает?
>> тут дело-то в том, что js никогда и не задумывался как язык
>> для разработки большого софта. а теперь его обвешивают костылями и пихают
>> невпих/емое.
> Ничего не напоминает?много всякого напоминает. но беседа-то у нас про js.
>и как же это может произойти на практике?Легко
>будет сразу заметен в течении 5 минут работы программы.После установки заказчику.
>> невежественные домыслы, ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> динамическая типизация - это отличный способ выстрелить себе в ногу или словить
> "отличный" стектрейс где-то из глубин библиотечного кода, просто потому что интерфейс
> строго не заданДавайте все-таки не путать динамическую/статическую типизацию и строгую/мягкую типизацию. Внезапно: есть ЯП в которых реализована строгая динамическая типизация. И в этих ЯП автоматического приведения к типу нет, а вот замыкания, инжекция кода и прочие вкусняшки, - напротив, имеются.
ЗЫ. А "борцам" с динамической типизацией из-за того, что у них автоматически привелись типы, а они это прощелкали, надо выстрелить не в ногу, а в голову - все равно она им не к чему.
отчасти-то он прав. потому что новоявленые МегаГуру про контракты, может, и слышали, но в виду отсутствия мозга ничего не поняли. соответственно, хвалёные библиотеки часто вместо контрактов светят половым гениталием. это ж «тормозит» и вообще «лишний код».с другой стороны — за отсутствие булевого типа и использование «+» для соединения строк таки надо было бы лишить обеда. и ужина.
А в каких языках динамическая типизация НЕ ВОЗМОЖНА?
Видимо, в языках со строгой типизацией. Например, Ada.
Мягкое и теплое, ага. В Python динамическая строгая типизация.
> Мягкое и теплое, ага. В Python динамическая строгая типизация.хорошая шутка.
Плохой юмор.Кто-то (не будем показывать пальцем) путает статическую и строгую типизацию.http://ru.wikipedia.org/wiki/%D0%A1%D1%8...
$python
>>> a = '2'
>>> b = a + 2Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>>
a = «fuck»;
a = 40;
print a+2;опа. это — не строгая типизация. какого хрена у 'a' — разные типы во время выполнения программы?
да, строгой без статики — увы. смиритесь.
впрочем, вколачивать ум в черепа любителям гвидобейсика — занятие неблагодарное. поэтому удаляюсь, бисера жаль.
> ВОЗМОЖНОСТЬ динамической типизации это плюс языкаТолько если ее делать не через опу. Т.е. с возможностью форсануть статическую для уменьшения грабель. А тут мало того что типизация динамическая, так еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект потом замахаешься дебажить в поисках опечатки.
>> ВОЗМОЖНОСТЬ динамической типизации это плюс языка
> Только если ее делать не через опу. Т.е. с возможностью форсануть статическую
> для уменьшения грабель. А тут мало того что типизация динамическая, так
> еще и несуществующие переменные без предупреждения и явного анонсирования такой хотелки
> кейвордом создадут. А вот это уже западлостроительство - мало-мальски крупный проект
> потом замахаешься дебажить в поисках опечатки.Приведите пример крупного проекта по созданию интерфеса программы.
> JS создал на автомате...как это он создал на автомате? кто ему разрешил самодеятельность? или мы рассматриваем случай когда программист забыл добавить 'use strict' в начало файла?
> ...си за такое сразу послал бы...анализатор статической типизпции -- не сделает за программиста его работу.
если ты написал (по ошибке)
memset(my_obj_ptr, 0, sizeof(my_obj_ptr));
вместо
memset(my_obj_ptr, 0, sizeof(*my_obj_ptr));то компилятор тебя не пошлёт (и темболее "сразу").
иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки.
однако статическая компиляция не палочка-выручалочка. по большей части она в основном только указывает на то что "чувак, ты хочешь же вывести на экран строку, а передаёшь в параметре число... ну забыл сконвертировать же!", а не на какую-то серъёзную штуку, которая годами может себя не проявлять.
> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием из-за того что думают будто компилятор находит все их ошибки.Некоторые не знаю, а в общем, как и все прочие, страдают забиванием. Сравнить, например, кол-во полезных подсказок, выдаваемых gcc на не-helloworld по дефолту и с -Wall -Wextra (-pedantic --std=c99 -Werror). А потом кол-во проектов, которые ближе ко второму. Особенно коммерческих.
> memset(my_obj_ptr, 0, sizeof(my_obj_ptr));Ну, вот конкретно такое достаточно хорошо ловится юниттестами, запущенными под валгриндом
> анализатор статической типизпции -- не сделает за программиста его работу.Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор и динамическое типизирование.
>> анализатор статической типизпции — не сделает за программиста его работу.
> Не сделает ВСЮ работу. Но часть сделает. Поэтому несколько глупо использовать интерпретатор
> и динамическое типизирование.не соглашусь. другое дело, что в js нет встроеного механизма указать типы, если надо. зато есть идиотия с использованием одного и того же оператора для сложения строк и чисел.
> не соглашусь. другое дело, что в js нет встроеного механизма указать типы,
> если надо. зато есть идиотия с использованием одного и того же
> оператора для сложения строк и чисел.Сравни OCaml и JS: в первом система статических типов, вывод типов методом ХМ (т.е. указывать тип можно, но не обязательно - он будет выведен), именованные параметры, значения параметров по-умолчанию. Единственная фигня - операторы для вещественных чисел /., *., +. и -., хотя никто не мешал перегрузить. Это, впрочем, исправлено в F#.
> Сравни OCaml и JSя окамла не знаю, увы. ну, так — на уровне «о! окамл! я не испуган, но озадачен.»
впрочем, сравнение всё равно некорректно: всё-таки js изначально не планировался как язык для написания чего-то сложнее, чем небольшие скриптики. в actionscript это попытались починить, но зачем-то притащили и симула-подобную (точнее, цпп-подобную) объектную модель.
(да, я знаю, что дефис не нужен; но с ним красивей)
беда js в том, что никто изначально не предполагал масштабов бедствия. а в итоге современные реализации js, например, должны бережно повторять глюки оригинального дизайна. с var, например, у которого scope — вся функция, а не блок. или с тем, что eval (который и так-то не особо нужен, но…), присвоеная переменной — уже не совсем та же самая eval.
> я окамла не знаю, увы. ну, так — на уровне «о! окамл!
> я не испуган, но озадачен.»Посмотри, не пожалеешь - штука маленькая, быстрая и очень удобная. Учебник по OCaml - http://caml.inria.fr/pub/docs/oreilly-book/ (где-то есть перевод на русский). Сочетает императивщину и функциональщину. И его идеи - более-менее передний край CS, как говорят специалисты, в 90-е научное развитие языковых средств остановилось (а индустрия это постепенно подсасывает).
После этого будет тяжко смотреть на С++ с его шаблонами и смешно на тутошние языковые споры.
> беда js в том, что никто изначально не предполагал масштабов бедствия.
Есть ещё чудесный PHP. :-)
>> я окамла не знаю, увы.
> Посмотри, не пожалеешь — штука маленькая, быстрая и очень удобная.да я знаю это — теоретически. а на практике как-то всё лениво, каждый раз на завтра откладываю.
> где-то есть перевод на русский
это не обязательно. %-)
> После этого будет тяжко смотреть на С++ с его шаблонами
да мне давно смешно.
> и смешно на тутошние языковые споры.
и так… собственно, после Scheme, где спокойно сочетается императивщина, функциональщина, разные объектные модели и pattern matching… разве только системы типов нет, хотя type inference поверх компилятора повесить несложно, code as data же.
>> беда js в том, что никто изначально не предполагал масштабов бедствия.
> Есть ещё чудесный PHP. :-)нененене. на js всё-таки можно писать, хоть и с трудом. но есть замыкания, лямбды и прочие приятные вещи. а у php одни костыли из каждой дырки и 100500 функций в global namespace. %-)
В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к одному.
> В экшнскрипт не плюсовую, а жабью модель притищали, причем почти один к
> одному.да у них у всех ноги из одного места растут.
> если ты написал (по ошибке)
> memset(my_obj_ptr, 0, sizeof(my_obj_ptr));
> вместо
> memset(my_obj_ptr, 0, sizeof(*my_obj_ptr));Во-первых, где здесь статическая типизация? Перепутана константа. Во-вторых, некоторые компиляторы выдают warning при компиляции такого (в gcc, вроде, было).
> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием
> из-за того что думают будто компилятор находит все их ошибки.С момента изобретения С прошло уже 40 лет, пора бы и на другие языки посмотреть. В частности, на ML/Haskell и подобные - там значительно более серьёзная система типов, нежели в С. И результаты работы анализатора типов, разумеется, тоже более серьёзные.
Он тоже не найдёт все ошибки, но результат явно будет лучше, чем в С, где можно поменять в memset 2 последних параметра местами и это пройдёт.
Ну тогда уже D порекламирую, благо он нынче вполне приятен. И вывод типов есть, и если надо в кишки залесть - пишешь unsafe и понеслось. А уж ranges - совершенно чудесная штука, которую никто, кажется, больше не сделал. И не заставляет ломать мозг функицональщиной вида "ехал лямбда через рекурсию монадой погоняя". При этом при надобности есть и иммутабельность, и алгебраические типы, и pure-функции, и карринг, и много других страшных слов :-)
не хватает только стандарта и нескольких компиляторов. кагбэ D1 уже нет, а D2 ещё толком нет. и нераспространено. но в остальном — надеюсь, что он в конце концов вытолкает цпп на обочину истории и легаси-кода.
> не хватает только ....Немного не так: кто ХОЧЕТ писать - тому всего хватает. Кто не хочет - тому ВЕЧНО чего-то нехватает, "мешается в танце" и т.п.
> D2 ещё толком нет.
Есть. Работающий компилятор, бери, да пользуйся!
> и нераспространено.
Как и любой язык без тонны говномаркетинга и бабла. Но при наличии разумных прогеров, легко вольётся в ряды. Вы же про него уже знаете! Я несколько перделок написал. Другие тоже не останутся в стороне, сравнив его с сипипями и цэшарпами.
>> не хватает только ….
> Немного не так: кто ХОЧЕТ писать — тому всего хватает. Кто не
> хочет — тому ВЕЧНО чего-то нехватает, «мешается в танце» и т.п.если ты пишешь себе приветмиры — то не вопрос, хоть для кнутовой шестибитовой машины пиши.
>> D2 ещё толком нет.
> Есть. Работающий компилятор, бери, да пользуйся!«есть» — это когда есть хотя бы две равноценные реализации и документ, на котором они базируются.
>> и нераспространено.
> Как и любой язык без тонны говномаркетинга и бабла.в си очень много вливали, да. и рекламировали на каждом углу.
> Но при наличии разумных прогеров, легко вольётся в ряды.
в качестве тестера — натурально. ничего плохого в этом нет, но мне неинтересно.
> Вы же про него уже знаете!
я про него знаю ещё с тех пор, как Уолтер его только сочинял.
> Я несколько перделок написал. Другие тоже не останутся в стороне,
> сравнив его с сипипями и цэшарпами.вот когда «не останутся» — тогда и стоит рассматривать в качестве языка для будущего проекта. а пока что вероятность подключения энтузиастов к проекту на c/c++ намного больше, чем та же вероятность для проекта на D. как минимум в силу того, что последних сильно меньше.
p.s. вообще, *лично для меня* язык подобного плана стоит более-менее серьёзно рассматривать тогда, когда в стандартном наборе gcc появится компилятор для этого языка.
>> иногда у меня вообще такое ощущение что некоторые Си-программисты страдают рассеянным вниманием
>> из-за того что думают будто компилятор находит все их ошибки.
> С момента изобретения С прошло уже 40 лет, пора бы и на
> другие языки посмотреть. В частности, на ML/Haskell и подобные - там
> значительно более серьёзная система типов, нежели в С.А разве в C есть что-то кроме char, int и float? Других типов нет - только "модификаторы" для указанных. Назвать это "системой типов"... мягко говоря, смешно.
> А разве в C есть что-то кроме char, int и float?да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что не надо уж совсем старичка унижать, он местами ещё вполне ничего.
>> А разве в C есть что-то кроме char, int и float?
> да. man typedef. структуры тоже отдельные типы. ranged-типов нет, правда. так что
> не надо уж совсем старичка унижать, он местами ещё вполне ничего.Никто его и не унижает. Но и превозносить его как божественное откровение и идеал - не стОит.
> Никто его и не унижает. Но и превозносить его как божественное откровение
> и идеал — не стОит.но в нише «переносимый макроассемблер» у него таки конкурентов нет.
> но в нише «переносимый макроассемблер» у него таки конкурентов нет.Вообще, можно было бы и улучшить косметически - сделать вывод типов, убрать неявные преобразования. А так - да, ассемблер.
нененене, не надо. а то мне будет скучно на нём писать. ;-)
>> Никто его и не унижает. Но и превозносить его как божественное откровение
>> и идеал — не стОит.
> но в нише «переносимый макроассемблер» у него таки конкурентов нет.Нет. К сожалению.
>Которое в большой программе потом икнется тем что JS создал на автомате некую переменную и прога через полчаса счета встала колом из-за трудноуловимого бага.Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт... да хоть на Фортране!
Тогда уже гуй на вебе, портабельности ради.
> Так разделите же дрозофил и котлеты. Т.е. гуй на QML, а счёт...А чем глюки в гуе лучше глюков в счете?
Очевидно, при глюках в гуе иногда можно взять другой, или CLI-вариант, над которым был гуй.
Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю программу на js. Хотя всем наплевать, все побежали быстро все переписывать на js, qml-же!
> Вы правы, но под qml обычно понимают декларативный интерфейс(который для десктопов и
> в пупок не упёрся, xml-ные формошлёпки куда приятней), а не всю
> программу на js. Хотя всем наплевать, все побежали быстро все переписывать
> на js, qml-же!Ну и как на xml подстветить неправильно заполенные поля при вводе?
> Ну и как на xml подстветить неправильно заполенные поля при вводе?точно так же, как и без него. тот, кто делает валидатор исключительно средствами GUI и его языка — идиот. а в нормальном случае всё равно понадобится механизм, при помощи которого основная софтина будет отмечать такие поля.
> через полчаса счетаКакого еще "счета"?
QML/JavaScript предназначены для создания GUI. "Счет" пиштеся как обычно - на C/C++.
> Сравнение охватывает такие вопросы, как удобство разработки, оценка трудозатрат, компактность кода, потребление памяти в процессе работы, скоросоть запуска, производительность итоговых приложений, визуальная привлекательность и т.п. Для оценки использовался Капитан Очевидностьfixed :)
А почему QML, а не чистый Qt?
Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям...
>Действительно а почему не чистый Си или машинный код?! Загадка какая-то прям...Где ты увидел в Qt чистый си? Развелось тут неучей, понимаешь.
Их саперы занимают памяти больше, чем ядро :(
> Их саперы занимают памяти больше, чем ядро :(Ну так ядро писали нормальные системщики, на сях, без халтуры. А это апликушники. Раздолбаи и пофигисты. Которых хлебом не корми, дай только индусский код понаписать.
Я правильно понимаю, что они сравнили императивный стиль программирования с декларативным? Или JS с Си? Тогда реквестирую сравнение Qt-C++ vs QML+js.
подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс или можно в свободное время?
> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорсПохоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...
>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс
> Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище....
>>> подскажи, а студентам-полотёрам-мс категорически запрещается писать опенсорс
>> Похоже, им категорически запрещается думать, поэтому и обсуждать с ними обычно нечего...
> Шигорин, ну ты-то завязывай уподобляться своей пастве! Позорище....Паства тут ни при чём, поскольку вопрос технический, а не духовный (и я сам паства). А с коллегами тут единодушен -- вещатели "правды", в том числе Вы лично, и тем более дешёвой рекламы MS -- здесь невостребованы вместе со своим (если вообще своим) мнением. Научитесь _слышать_, а не только вещать -- приходите.
Сколько раз это надо повторить, чтобы дошло?
PS: слово "правда" забрано в кавычки потому, что выставляете как правду либо неправду, либо смесь правды с ложью; либо недоговариваете.
>>При этом различия в производительности и потреблении ресурсов оказались не такими заметными как можно было предположить.А вес фрэймворка интересно сравним?
очень ценное сравнение от человека, который:
«Please note these are only my guesses — guesses of developer neither much experienced in plain C nor in EFL.»в принципе, дальше и разбирать неинтересно.
Бенчмарк может произвести и непрограммист.Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт.
> Бенчмарк может произвести и непрограммист.ага. а домоходяйка — управлять государством.
> Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть
> — факт.это не факт, это теория. то, что яростные обличители и находители простоты не знают, как работает Edje и Embryo, и как создаются интерфейсы в EFL — даже не удивительно. удивительно было бы, если бы знали.
офтоп> ага. а домоходяйка — управлять государством.
Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно.
а по теме - сравнивать довольно небольшой набор C библиотек и огромный плюснутый qt/qml - бред. еще больший бред кодить интерфейсы на C. Гр. интерфейс по своей природе декларативен. и стараться писать его в 21 веке надо в чём угодно, только не в императивных языках.
> Видимо удобно.ну, гейтсу же приписывают высказывание про 640 кб. пусть и ленин пострадает.
> а по теме — сравнивать довольно небольшой набор C библиотек и огромный
> плюснутый qt/qml — бред.сравнивали удобство создания морды как раз, и сопряжения её с логикой. тут как раз всё более-менее нормально.
> еще больший бред кодить интерфейсы на C.
именно поэтому в EFL так делают только любители Elementary. для Edje морда делается на Embryo и описывается местами похоже на qml. там внутри почти pawn есть, специально для всяких нестандартных переходов и анимашек. но можно и без него, получается всё равно симпатично. конечно, морду можно заменять, вплоть до вообще переделать.
> Гр. интерфейс по своей природе декларативен.
ровно до тех пор, пока декларации поддерживают хотелки. как только хотелки выходят за рамки — начинается разного рода битьё в бубен.
>Будьде добры, не выдирайте цитату с кровью, иначе Ленин вас покусаетъ. Он говорил "Каждая кухарка может управлять государством, если её научить." Почему-то большинство забывает конец фразы. Видимо удобно.Тогда уж будьте добры сами цитировать правильно и не придумывать не существующих концов.
"Мы не утописты. Мы знаем, что любой чернорабочий и любая кухарка не способны сейчас вступить в управление государством. Но мы требуем немедленного разрыва с тем предрассудком, будто управлять государством, нести будничную, ежедневную работу управления в состоянии только богатые или из богатых семей взятые чиновники."
«Удержат ли большевики государственную власть?» 1917.
ну, *по сути* он правильно сказал. разве что не надо было заявлять это как цитату.
> ну, *по сути* он правильно сказал. разве что не надо было заявлять
> это как цитату.Нет. *По сути*, анонимус переврал, как и ты (кстати, слегка отредактировал и последний аноним :-). У ВИЛ утверждается не то, что КАЖДАЯ кухарка может, а что НЕ ТОЛЬКО богатые чиновники могут. Т.е. среди людей, не являющихся богатыми чиновниками есть люди, способные управлять государством. Совершенно не обязательно, что эти люди - кухарки или чернорабочие.
Т.е. из цитаты ВИЛ вообще не следует даже, что "хоть одну кухарку можно научить управлять государством", не говоря уж о "КАЖДОЙ кухарке". :-)
хм. да, признаю, ступил. пардон.
> Ну а то, что на QML писать легче чем на EFL\GTK+\Motif\нужное подчеркнуть - факт.Поэтому низкокачественного и глючного быдлокода будет больше.
Про отладку ни слова. Это здорово. Можно за пять минут написать на qml и день отлавливать баги. А можно день писать код и 5 минут потратить на отладку. Имхо, я люблю писать код, а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни слова. Ни средствами IDE, ни самописными скриптами. Ждем продолжения.
> Про отладку ни слова. Это здорово. Можно за пять минут написать на
> qml и день отлавливать баги. А можно день писать код и
> 5 минут потратить на отладку. Имхо, я люблю писать код,
> а не заниматься тестированием. Кстати про профилирование, тестирование (любое) тоже ни
> слова. Ни средствами IDE, ни самописными скриптами. Ждем продолжения.Если думать когда пишешь код, то можно за пять минут написать код и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны.
> Если думать когда пишешь код, то можно за пять минут написать код
> и пять минут потратить на отладку. Отладка - крайнее средство когда логи бесполезны.В теории все просто. На практике когда будет какая-нибудь навороченная, многопоточная, event-driven прога - вы опупеете что с отладкой, что с логами. Особенно когда проблемная ветка кода вызывается только после дождичка в четверг високосного года, например.
А с логами - это уже не отладка, по вашему? Только если пошагово в дебаггере прыгать? Впрочем, отладку гуя по логам - это, конечно, "гениальное" предложение.
> Впрочем, отладку гуя по логам — это, конечно, «гениальное» предложение.нормальное вполне. отладчик в принципе неудобен, и не только для этого. в идеале вообще желательно внутри софта иметь командную консоль, откуда можно тормознуться и исследовать/менять состояние софта. ну да, встроеный отладчик получается. а если там ещё и monkey pathcing есть…
