> Тогда возьми MK51 и сиди программи. Да еще и ЖКИ экран на халяву считай :)

МК-51 совсем не программируемый калькулятор. Вот МК-52 и 61, те да, программируемые. Но экран там уже не ЖК.

Можно еще вспомнить МК-85, на котором можно было хранить 10 программ на бейсике.

У меня до сих пор лежат дома рабочие МК-51, 61 и 85. Причем 51-й выпуска 89-го года. :)

Получилось что-то типа WebForms, только не совместимое со стандартами и толстоклиентное. Гм... посчупать можно. Как будет свободное время - надо будет скачать.

2kalpa Вопросик : Почему, к примеру, не Xforms ?

Собственно, он удовлетворяет всему предложенному, более того - стандартизирован и имеет кое-какие реализации. Xforms во многом покрывает проблемы с интерактивностью HTML решений, оставляя их возможности. Не без проблем все это хозяйство. но мне кажется серьезным шагом.

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

маразм и идиотизм c++ кодеров достиг своего апофигея

>не понимая что это никому не надо

ну если понимать под "все" даунов не смогших асилить плюсы и красноглазых религиозных фанатиков, то я согласен с твоим постом

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

>мега_крутаяая_иконка_из_КеДеЕей

о. еще один индивид которого избили кде-шники :)

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

точно. мы удивлены что к нам на лор заявился пещерный мега гуру редактирующий графику и правящий фото в ascii

>зачем компутеру ресурсы нужны кроме как на гуй

qt - это не только виджеты, ламерье. почитай маны, а потом лезь на лор

по-моему это как раз ещё один способ НЕ написать клиент-серверное приложение :)

--седайко стюмчик

Ещё хочется отметить, что аффтар изобретает велосипед. Давно уже существуют фрэймворки, которые позволяют делать подобное. Например, Java Server Faces.

--седайко стюмчик

>Например, Java Server Faces

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

>Например, Java Server Faces.

Java это платформа со многими возможностями.

C++ - это язык программирования, а вот C++ + Qt это тоже платформа (с поддержкой сети, потоков, юникода, баз данных..., а не просто GUI "морд"). Поэтому неудивительно, что в данном случае используется Qt.
Ведь C++ + Qt это фактически единственный способ использовать ява принцип "написал однажды - работает везде" на плюсах. А это далеко не бесполезеное свойство для клиент-серверных приложений.

>>Например, Java Server Faces

> qt - это компилированный а не байт-код. значит скорость. а джабы у многих нет и нафик не нужна

Угу. а qt стоит на всех серверах. лол :)

КАКОГО ФИГА БЫЛО ТОГДА ТАКУЮ ФИГНЮ НЕСТИ

Надо было "забудьте о клиент-сервере, пишите сервер и клиент как одно", разве не так?

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

>ну почему же? Клиенту гуй нужен а вот серверу он действительно нет.

А что не qt, то не гуй?

Если ты _потрудишься_ и сваяешь прикладуху в QT, то поставить фреймворк на сервак, поверь, для тебя не составит особого труда. Разработка и установка, несколько отличаются по _трудоёмкости_ . Так-что не надо ля-ля...

Тоже самое я могу сказать тебе и по поводу Java. JSF - серверная технология.

>Угу. а qt стоит на всех серверах. лол :)

Мож что не понимаю, а статически библиотеки включить нельзя?

> А как с Gtk - не знаю, его в комм. приложениях мало используют.

Были проблемы. А может и сейчас есть. Не знаю. Всё можно исправить. :) Что касается комерческих приложений - это _пока_ мало используют. Стараниями Novell и RedHat на Linux у Gtk хорошие перспективы, которые пригодятся при переносе на win изначально нативных linux-приложений.

автору бесплатные советы (у нас же страна советов :) ):
* сразу же SSL прицепить (если ещё не сделано), иначе инфа (пароли к примеру) по сети в открытом виде ходят
* как там с обработкой ошибок? (сколько матюков в своё время было послано в адрес RPC)
* как насчёт компрессования/кеширования битмапов?

>qt - это не только виджеты, ламерье. почитай маны, а потом лезь на лор

лемрье это ты - где я писал что qt это только toolkit ??? я сразу обозначил что это framework - так что сначала научись а потом лезь на лор.

>Были проблемы. А может и сейчас есть.

"неокторые трудности конечно есть" - которые заключаются в кривизне рук, просто в данном вопросе с Qt будет проще - но gtk+ & Co продвигаются в этом вопросе, просто достали некоторые ламеры которые сравнивают *only* gtk+ и Qt - все таки тулкит сравнивать с фреймворком в котором какого только гауна не понапихано - есть несерьезно.

>* сразу же SSL прицепить (если ещё не сделано), иначе инфа (пароли к примеру) по сети в открытом виде ходят
>* как там с обработкой ошибок? (сколько матюков в своё время было послано в адрес RPC)
>* как насчёт компрессования/кеширования битмапов?

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