микрософто-дотнетовские псы

[metaclass]

ссылко 1
Ссылко 2

Микрософт угробит сама себя, это как факт. Я .NET почти не рассматриваю как потенциальную платформу для новых разработок исключительно из-за того, что микрософт меняет его версии, как перчатки, и уже успела прекратить поддержку первого фреймворка.
Да и убог он для десктопных приложений, так же как и жаба. Бесит это.

Comments

[jtootf.livejournal.com]

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

[mr-st.livejournal.com]

То бишь UI таки придется писать на плюсах?

[jtootf.livejournal.com]

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

однако таких проектов всё же меньшинство

[jtootf.livejournal.com]

естественно, разумеется, само собой - нет

или что, реализация контрола - это UI? или UI это всё-таки что-то большее, чем реализация всех используемых виджетов вместе взятых? Tk полностью написан на K&R C, однако из этого не следует что писать UI на Tcl/Tk и писать UI на K&R C - одинаковая по сложности задача, n'est-ce pas?

[mr-st.livejournal.com]

я к тому что будет фарш из разных языков а это не есть гуд

[jtootf.livejournal.com]

это ещё почему? без аргументов не принимается :)

[mr-st.livejournal.com]

ответил ниже

[j-sheridan.livejournal.com]

А вы не в курсе, что сейчас любой проект одним языком не обходится? Как минимум 2, а то и 3.

[mr-st.livejournal.com]

И что? Мне от этого легче что-ли?

[dizel-by.livejournal.com]

Глубокоуважаемый ребе metaclass категорически с этим не согласится. Ибо поддерживать монолит в условиях червей и жаб заказчика намного проще. А несколько языков редко когда соберутся в идеологически верный монолит.

[mr-st.livejournal.com]

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

[jtootf.livejournal.com]

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

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

Плюс при саппорте нужно иметь в штате спецов по каждой технологии а лучше спеца знающего на приемлемом уровне все технологии входящие в приложение. Геморрой.

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

[mr-st.livejournal.com]

Ресурсы в виде человеов нынче не сильно доступны :) Некоторые затраты пойдут на коммуникацию между разработчиками разных технологий. Опять же на саппорт хочется сажать менее квалифицированных девелоперов - проблема со знаниями этих разных технологий или как вариант большее кол-во девов на саппорте. Вопрос как эффективно загрузить работников разных технологий чтоб они не простаивали, При одноязыковости/однотехнологичности :) эта проблема стоит менее остро ИМХО

ПС одноязыковость еще не означает монолит. Это скорее вопросы архитектуры

[metaclass.livejournal.com]

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

[j-sheridan.livejournal.com]

:)
К примеру сайт возьмем с бд в постгресе. Итого: php+sql+(pl/sql|perl|python)+html+css+js
Ну хорошо, приложение на кутэ: sql+css?(если скиновать собираемся)+html(ричтекст будет у нас в приложении?)+c++
А ты говориш - 2 языка:)

[archangel-rhn.livejournal.com]

html+css+js
Эта цепочка - одного поля ягоды. JavaScript не настолько велик, чтобы на изучение его следовало бы тратить существенное время. CSS - субстрат HTML.
php+sql+mysql
Также одна связка.

[jtootf.livejournal.com]

до недавних пор существенным плюсом была ещё и открытость. относительным плюсом - наличие Qtopia (не знаю, насколько хорошо у .Net с embedded,- в любом случае NOKIA не просто так сделала ставку именно на Qt), лёгкость миграции desktop-embedded

кстати, как у .Net с модульностью? могу я оторвать от него только тот кусок функционала, который мне реально нужен (и помещается в ~500Kb)?

[metaclass.livejournal.com]

Это еще одна из проблем .NET - он тянет за собой мегабайты фреймворка. Хотя конечно, поставить его никакой проблемы нет.
А еще он падла, интегрируется в систему так, что проблемы с конфигурацией могут затронуть несколько приложений - невозможно изолироваться.

[jtootf.livejournal.com]

вот уже можно складывать проблемы на весы - Qt/.Net, и принимать решение в зависимости от того, какие из проблем применительно к предметной области имеют больший вес. но в общем говорить что Qt не альтернатива .Net'у - глупо

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

[komarov.livejournal.com]

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

[j-sheridan.livejournal.com]

Можно.

[tonal.myopenid.com (from livejournal.com)]

Использую Qt + Python уже больше 3х лет. Перешёл с Delphi. Полёт нормальый.
Свой котрол пишется несколькими способами в зависимости от того, что нужно.
Плюсы пока подтягивать не приходилось хотя такая возможность всегда есть. :)