Comments 46
Про Qt забыли.
биндинги морально устарели :)
последний релиз датируется
Sep 19th, 2003 — Release of PerlQt-3.008 ChangeLog
Sep 19th, 2003 — Release of PerlQt-3.008 ChangeLog
2008 год, русский разработчик:
search.cpan.org/~vadiml/QtGui-4.004/
search.cpan.org/~vadiml/QtCore-4.004/
search.cpan.org/~vadiml/QtGui-4.004/
search.cpan.org/~vadiml/QtCore-4.004/
gui приложения на perl это изврат высшей степени
1) они сами по себе очень тормозные
2) вид оставляет желать лучшего (если вид «родной» то тормозят вдвойне)
1) они сами по себе очень тормозные
2) вид оставляет желать лучшего (если вид «родной» то тормозят вдвойне)
1) Не правда. Перл производительности уровня питона, а на питоне оно не тормозит. Как пример посмотри SPE на wxPython: полноценная(!!) IDE. Не тормозит даже на древнейшем железе.
2) Не правда. Используйте wx/qt. У них дефолтный вненшний вид. Как пример, тот же SPE.
Прежде, чем что-то говорить, неплохо бы разобраться в теме хоть немного.
P.S. Скриншот: i029.radikal.ru/0805/81/ec5978e2b521.png
2) Не правда. Используйте wx/qt. У них дефолтный вненшний вид. Как пример, тот же SPE.
Прежде, чем что-то говорить, неплохо бы разобраться в теме хоть немного.
P.S. Скриншот: i029.radikal.ru/0805/81/ec5978e2b521.png
Вот еще скрины в догонку, Padre (Perl+Wx):
padre.perlide.org/trac/wiki/Screenshots
Работает на ура, иногда пользуюсь.
padre.perlide.org/trac/wiki/Screenshots
Работает на ура, иногда пользуюсь.
мда, весело, тема про гуй на пхп вызвала эпический холивор, с упреками о говноязыке пхп
ну а с перлом не, все ок, можно писать говногуи, по своим характеристикам сравнимые с технологиями конца 20 века
троллим
ну а с перлом не, все ок, можно писать говногуи, по своим характеристикам сравнимые с технологиями конца 20 века
троллим
perl «православен»
ну и чем он православней пэхэпэшечки-то? на них обоих можно писать gui, но разрабатывались ли они изначально под это? а костыли это «не православно» имхо
вообще есть всем известные С С++ Pascal, наконец VB и VB.NET
и кавайные идеешечки к ним ^_^
вообще есть всем известные С С++ Pascal, наконец VB и VB.NET
и кавайные идеешечки к ним ^_^
С — нет объектов, очень тяжело программировать :(
C++ — есть объекты, но дурацкий синтаксис, надо описать у каждого по 5 корнструкторов, нет параметров со значениями по умолчанию, надо писать хедеры, нет авт. управления памятью, нет встроенных высокоэффективных опреаций со строками или массивами. Синтаксис 20-летней давности, нет делегатов ну и много еще чего, хотя можно было бы и сделать! При работе возникает много утечек памяти и всяких access violations.
VB —вообще ужас имхо.
Есть, правда язык D, в нем почти все есть, но он вроде со сборщиком мусора (фууу :( ), и от шаблонов и строгой типизации там тоже не смогли избавиться.
На чем писать Гуи то?
p.s Питон и Руби само собой не катят, едят память как бешенные и не компилируются в ассемблер.
C++ — есть объекты, но дурацкий синтаксис, надо описать у каждого по 5 корнструкторов, нет параметров со значениями по умолчанию, надо писать хедеры, нет авт. управления памятью, нет встроенных высокоэффективных опреаций со строками или массивами. Синтаксис 20-летней давности, нет делегатов ну и много еще чего, хотя можно было бы и сделать! При работе возникает много утечек памяти и всяких access violations.
VB —вообще ужас имхо.
Есть, правда язык D, в нем почти все есть, но он вроде со сборщиком мусора (фууу :( ), и от шаблонов и строгой типизации там тоже не смогли избавиться.
На чем писать Гуи то?
p.s Питон и Руби само собой не катят, едят память как бешенные и не компилируются в ассемблер.
Я вот недавно тоже задался таким вопросом. Плюс у меня еще была в требованиях кроссплатформенность. Всё к чему удалось прийти — Java. К сожалению не нашел в себе моральных сил ее освоить. Знающие люди говорят, что сама по себе она несложна в освоении, для опытного программера. Но вот с фреймворками придется поразбираться…
мм… а почему VB и VB.Net ужас-то?
к последнему есть тулза для коннекта к mySQL например, так что вот Вам инструменты для гуи со всеми прелестями VB и централизованным обменом данных
к последнему есть тулза для коннекта к mySQL например, так что вот Вам инструменты для гуи со всеми прелестями VB и централизованным обменом данных
>C++ — есть объекты,… нет авт. управления памятью
>Есть, правда язык D, в нем почти все есть, но он вроде со сборщиком мусора (фууу :( )
Вы определитесь, сборщик мусора вам нужен или нет? В D его, кстати, можно и не использовать.
>p.s Питон и Руби само собой не катят, едят память как бешенные и не компилируются в ассемблер.
Реализации действительно оставляют желать, в сравнении с реализациями Scheme и Common Lisp. Ждем Unladen Swallow.
>Есть, правда язык D, в нем почти все есть, но он вроде со сборщиком мусора (фууу :( )
Вы определитесь, сборщик мусора вам нужен или нет? В D его, кстати, можно и не использовать.
>p.s Питон и Руби само собой не катят, едят память как бешенные и не компилируются в ассемблер.
Реализации действительно оставляют желать, в сравнении с реализациями Scheme и Common Lisp. Ждем Unladen Swallow.
> В D его, кстати, можно и не использовать.
А delete руками что ли писать? Ну будьте реалистом, в программе среднего или большого размера это просто невозможно, все силы разработчика будут уходить на поиск утечек памяти, да и неправильно как-то это, думать где освободить память, пусть железка думает а не я.
А delete руками что ли писать? Ну будьте реалистом, в программе среднего или большого размера это просто невозможно, все силы разработчика будут уходить на поиск утечек памяти, да и неправильно как-то это, думать где освободить память, пусть железка думает а не я.
>Реализации действительно оставляют желать, в сравнении с реализациями Scheme и Common Lisp
У Scheme толком тоже нету нормальных (быстрых) реализаций. Есть gambit-c, он более-менее. Для Common Lisp есть SBCL, но там производительности можно добиться только нечестно — добавляя типизацию в код (типа так: (declare (fixnum var)))
>Ждем Unladen Swallow.
Ну Q2 вышел уже, только что-то 5 кратного прироста производительности там нету, максимум 30-50%.
Есть «компромисный» вариант — языки с выводом типов, которые могут эффективно компилироваться. Они как правило либо чисто функциональные (Haskell), либо смешанно-функциональные (OCaml, Scala).
А еще есть С++, и он адски сложный в изучении=)
У Scheme толком тоже нету нормальных (быстрых) реализаций. Есть gambit-c, он более-менее. Для Common Lisp есть SBCL, но там производительности можно добиться только нечестно — добавляя типизацию в код (типа так: (declare (fixnum var)))
>Ждем Unladen Swallow.
Ну Q2 вышел уже, только что-то 5 кратного прироста производительности там нету, максимум 30-50%.
Есть «компромисный» вариант — языки с выводом типов, которые могут эффективно компилироваться. Они как правило либо чисто функциональные (Haskell), либо смешанно-функциональные (OCaml, Scala).
А еще есть С++, и он адски сложный в изучении=)
>У Scheme толком тоже нету нормальных (быстрых) реализаций.
Как это нету? А как же Bigloo, PLT Scheme, Larceny? Пошустрее питона будут.
>Они как правило либо чисто функциональные (Haskell), либо смешанно-функциональные (OCaml, Scala).
Clean забыли. :)
>А еще есть С++, и он адски сложный в изучении=)
Не только в изучении. ;)
Как это нету? А как же Bigloo, PLT Scheme, Larceny? Пошустрее питона будут.
>Они как правило либо чисто функциональные (Haskell), либо смешанно-функциональные (OCaml, Scala).
Clean забыли. :)
>А еще есть С++, и он адски сложный в изучении=)
Не только в изучении. ;)
Чем оно лучше аналогичных решений на других языках?
Речь идет не о выборе языка, а о выборе средства разработки интерфейса для перл-программиста. Сейчас языки типа перла, питона, руби предоставляют примерно одинаковые возможности, просто отношение ко многим вещам разное. Поэтому сейчас выбор языка это не выбор каких-то параметров, а подбор удобного ОПРЕДЕЛЕННОМУ программисту инструмента. Вообще, я надеюсь, что с появлением качественных компиляторов для всех более-менее популярных языков на Parrot, холиварщики призаткнутся.
> Поэтому сейчас выбор языка это не выбор каких-то параметров, а подбор удобного ОПРЕДЕЛЕННОМУ программисту инструмента.
В каких объективных терминах выражается удобство?
Вот допустим, есть вполне конкретная задача. Дана формочка, с которой мы хотим получить данные. Используя wxHaskell+wxGeneric, можно быстренько отобразить контролы формы на структуру данных (умненький компилятор сделает все сам, практически без нашего вмешательства). Если не пользоваться wxGeneric, тогда весь код перекидывания данных туда-сюда (между GUI и структурой данных) придется писать ручками, что чревато.
Что Перл может предоставить программисту в этой задаче?
> Вообще, я надеюсь, что с появлением качественных компиляторов для всех более-менее популярных языков на Parrot, холиварщики призаткнутся.
Причем тут холиварщики? Parrot будет к концу года вроде бы, а там уж и Unladen Swallow, и еще V8… Скоро наконец догонят древний Common Lisp.
В каких объективных терминах выражается удобство?
Вот допустим, есть вполне конкретная задача. Дана формочка, с которой мы хотим получить данные. Используя wxHaskell+wxGeneric, можно быстренько отобразить контролы формы на структуру данных (умненький компилятор сделает все сам, практически без нашего вмешательства). Если не пользоваться wxGeneric, тогда весь код перекидывания данных туда-сюда (между GUI и структурой данных) придется писать ручками, что чревато.
Что Перл может предоставить программисту в этой задаче?
> Вообще, я надеюсь, что с появлением качественных компиляторов для всех более-менее популярных языков на Parrot, холиварщики призаткнутся.
Причем тут холиварщики? Parrot будет к концу года вроде бы, а там уж и Unladen Swallow, и еще V8… Скоро наконец догонят древний Common Lisp.
Извините. Неправильно воспринял ваш ответ.
> Вот допустим, есть вполне конкретная задача. Дана формочка, с которой мы хотим получить данные. Используя wxHaskell+wxGeneric, можно быстренько отобразить контролы формы на структуру данных (умненький компилятор сделает все сам, практически без нашего вмешательства). Если не пользоваться wxGeneric, тогда весь код перекидывания данных туда-сюда (между GUI и структурой данных) придется писать ручками, что чревато.
Виджеты Tk имеют свойство textvariable. Поэтому данные, которые вы вводите, будут храниться в переменных.
my $ok = 'OK';
my $button = $main_window->new_ttk__button( -textvariable => \$button );
изменяя $ok изменится и надпись на кнопке.
Виджеты Tk имеют свойство textvariable. Поэтому данные, которые вы вводите, будут храниться в переменных.
my $ok = 'OK';
my $button = $main_window->new_ttk__button( -textvariable => \$button );
изменяя $ok изменится и надпись на кнопке.
начал цикл статей о разработке с использованием Tkx.
santeri.habrahabr.ru/blog/65466/
santeri.habrahabr.ru/blog/65466/
А почему все-таки Tkx, а не не Wx? Какие сложности были при установке?
Tkx потому что:
1. ActiveState PPM, PDK написаны с использованием этой библиотеки.
2. Гарантированно (проверял везде) работает на Windows, Mac OS X, Linux, Solaris.
3. «Родное» оформление.
4. Мне необходимо использовать событийную машину (POE), поддержка Wx слабо реализована
search.cpan.org/~mike/POE-Loop-Wx-0.04/lib/POE/Loop/Wx.pm
а в случае с Tkx, «мост» уже почти написан, скоро засабмичу в CPAN ;)
5. В бинарном файле места занимает в два раза меньше.
1. ActiveState PPM, PDK написаны с использованием этой библиотеки.
2. Гарантированно (проверял везде) работает на Windows, Mac OS X, Linux, Solaris.
3. «Родное» оформление.
4. Мне необходимо использовать событийную машину (POE), поддержка Wx слабо реализована
search.cpan.org/~mike/POE-Loop-Wx-0.04/lib/POE/Loop/Wx.pm
а в случае с Tkx, «мост» уже почти написан, скоро засабмичу в CPAN ;)
5. В бинарном файле места занимает в два раза меньше.
Слушайте, в Перле же если я не путаю, очень извратный синтаксис, так что ничего не понять? И я слышал там даже аргументы функциям как-то извратно передаются, через $@, а не скобки, а уж объекты там вообще непонятно как делать. Как на нем вообще можно писать что-то?
Синтаксис извратным кажется, когда Вы не знакомы с ним. Согласен.
Но по изучении, Вы поймете что ошибались.
На самом деле все просто. Аргументы передаются через вектор @_.
Приведу небольшой пример: необходимо написать подпрограмму(sum) которая суммирует два числа.
my $result = sum( 3, 4 ); # result = 7
варианты
sub sum {
my( $a, $b ) = @_; # распаковываем все сразу
return $a + $b;
}
sub sum {
my $a = $_[0];
my $b = $_[1];
return $a + $b;
}
sub sum {
my $a = shift @_;
my $b = shift @_;
}
так как shift без явного задания аргумента, извлекает первый элемент из _ то можно написать
sub sum {
my $a = shift;
my $b = shift;
return $a + $b;
}
можно и вообще return опустить
sub sum {
$_[0]+$_[1];
}
Хоть оно и будет работать, но так писать не следует. (хотя для perlgolf'ов сойдет :)
Нужно придерживаться стилю программирования.
«There's more than one way to do it» — Larry Wall.
А вот и другой пример: написать подпрограмму которая будет суммировать все переданные ей числа
my $result = sum( 1, 4, 6, 7 ); # 18
sub sum {
my $s = 0;
$s += $_ foreach( @_ ); # прибавляем к $s каждый элемент из @_
return $s;
}
Perl это искусство :)
Но по изучении, Вы поймете что ошибались.
На самом деле все просто. Аргументы передаются через вектор @_.
Приведу небольшой пример: необходимо написать подпрограмму(sum) которая суммирует два числа.
my $result = sum( 3, 4 ); # result = 7
варианты
sub sum {
my( $a, $b ) = @_; # распаковываем все сразу
return $a + $b;
}
sub sum {
my $a = $_[0];
my $b = $_[1];
return $a + $b;
}
sub sum {
my $a = shift @_;
my $b = shift @_;
}
так как shift без явного задания аргумента, извлекает первый элемент из _ то можно написать
sub sum {
my $a = shift;
my $b = shift;
return $a + $b;
}
можно и вообще return опустить
sub sum {
$_[0]+$_[1];
}
Хоть оно и будет работать, но так писать не следует. (хотя для perlgolf'ов сойдет :)
Нужно придерживаться стилю программирования.
«There's more than one way to do it» — Larry Wall.
А вот и другой пример: написать подпрограмму которая будет суммировать все переданные ей числа
my $result = sum( 1, 4, 6, 7 ); # 18
sub sum {
my $s = 0;
$s += $_ foreach( @_ ); # прибавляем к $s каждый элемент из @_
return $s;
}
Perl это искусство :)
Вот-вот, вы только и подтвердили мою мысль, что Перл — изврат (ну или искусство :) по вашему ), во-первых, путаешься же, во-вторых, мне в свое время надоело писать эти my () = @_ в начале каждой функции. Куча двусмысленностей, типа контекста массива/литерала (или как оно назывется?) или операторы if *после* строки с кодом. Синтаксис мозг выносит напрочь! страшно представить себе большой файл с таким кодом.
Большой — страшно, но маленькие скрипты очень удобно писать.
чепуха, так можно о любом языке программирования сказать не особо вникая в суть
1. в Perl есть прототипы, для тех кто любит указывать тип передаваемых данных в функции (ну и не только для них =) )
2. мне в свое время надоело писать эти my () = @_ в начале каждой функции — чепуха,
во-первых это не обязательно писать
во-вторых менять список типов и названий аргументов у функций при рефакторинге, более утомительное занятие
ну и наконец:
вместо того чтобы повторять какие-то несуществующие мифы и придумывать несуществующие проблемы, проще попытался бы ознакомиться, что это за язык и «с чем его едят», для Perl самая замечательная (и очень занимательная!!! что достаточно непривычно в области изучения языков программирования) книга по программированию которую я когда либо читал в жизни — Программирование на Perl (3-е изд.) [Л. Уолл, Т. Кристиансен, Д. Орвант]
1. в Perl есть прототипы, для тех кто любит указывать тип передаваемых данных в функции (ну и не только для них =) )
2. мне в свое время надоело писать эти my () = @_ в начале каждой функции — чепуха,
во-первых это не обязательно писать
во-вторых менять список типов и названий аргументов у функций при рефакторинге, более утомительное занятие
ну и наконец:
вместо того чтобы повторять какие-то несуществующие мифы и придумывать несуществующие проблемы, проще попытался бы ознакомиться, что это за язык и «с чем его едят», для Perl самая замечательная (и очень занимательная!!! что достаточно непривычно в области изучения языков программирования) книга по программированию которую я когда либо читал в жизни — Программирование на Perl (3-е изд.) [Л. Уолл, Т. Кристиансен, Д. Орвант]
C GUI на перле я разбирался несколько лет назад и даже несколько программ написал для людей. Вывод — для реальной разработки он малопригоден, при манипулировании большим количеством данных торможение невероятное. Perl-Tk удобен для мастерения небольших формочек, но отсутствие вменяемых пакетов для построения этих формочек вынуждает всё делать руками. В результате быстрее выучить С# для Mono или Java, чем долбиться с перлом и в один прекраснй момент обнаружить, что в мультитредовом режиме принципиально работать он не хочет.
Это всё касается Perl+Tk, Wx я не пробовал.
Это всё касается Perl+Tk, Wx я не пробовал.
Cам наступал на те же грабли. Заставить работать Tk+threads можно, если потоки задавать ДО создания UI.
Правда там и в документации было написано что «Tk isn`t thread-safe»
Рабочая модель это Boss/Workers + Queue.
Правда там и в документации было написано что «Tk isn`t thread-safe»
Рабочая модель это Boss/Workers + Queue.
Год-два назад мне не удалось этого сделать. Сам гуи запускался, но после того, как управление попадало в поток (т.е. после того, как на кнопку любую нажмешь) — все крашилось со страшными ругательствами. Потоки создавал и до, и после, и «посередине» :)
Буду благодарен, если осветите эту тему в статьях.
Буду благодарен, если осветите эту тему в статьях.
не холивара ради, а просто вставлю ремарку
вчера начал плотно осваивать PyQt4
очень нравится, все весьма логично, но маны читать приходится много
вчера начал плотно осваивать PyQt4
очень нравится, все весьма логично, но маны читать приходится много
Наткнулся недавно в интернете на одну разработку, называется Win32::GUI:
Это инструментарий для работы с графическим интерфейсом Win32 из Perl. Представляет собой XS-реализацию большинства функций из user32.dll и gdi32.dll с объектно-ориентированным perl-интерфейсом и основанной на событиях моделью диалогов.
Это инструментарий для работы с графическим интерфейсом Win32 из Perl. Представляет собой XS-реализацию большинства функций из user32.dll и gdi32.dll с объектно-ориентированным perl-интерфейсом и основанной на событиях моделью диалогов.
счастливые вы люди, если можете выбирать, на чём писать.
у нас в конторе все гуи исключительно на делфи, с радостью бы использовал перл, ничего устаревшего в нём нет. *nix вообще с 60-х годов, но устаревшим никто не называет :)
у нас в конторе все гуи исключительно на делфи, с радостью бы использовал перл, ничего устаревшего в нём нет. *nix вообще с 60-х годов, но устаревшим никто не называет :)
Есть еще Prime.
Sign up to leave a comment.
Perl и GUI. Сравнение тулкитов