Здравствуйте, Ночной Смотрящий, Вы писали:
vaa>>ручное управление памятью.
НС>Почему для тебя в контексте гуя это важно?
Подозреваю, что при динамическом выделении памяти на множество мелких элементов, с автоматическим управлением оной, накладные расходы должны быть довольно ощутимы.
VK>Ну уж не знаю. Я помню как в двухтысячных впервые увидел QT на Windows.
В ранних или поздних 00-х? Это важно.
VK>Просто демка, типа kitchen sink, тормозила жесточайше. Даже приснопамятный MFC летал по сравнению с этим творением.
В конце нулевых Qt 4 отточили до вполне сносного качества: ничего уже не тормозило, и довольно приятные визуальные стили появились. Да и после пересборки самого Qt с выкидыванием тонны ненужных лично мне свистоперделок, удалось довести размер виндового статически линкованного exe до двух с небольшим мегов, а после upx так и вообще влезало на дискету. Так что тяжесть — тоже мимо, надо просто немножко с ним повозиться, а не брать как есть.
К слову, та же известная и дорогущая IDA Pro сделана на Qt, и отлично себя чувствует и под виндой, и под маком, и под линуксом. Да, она ещё та черепаха, но связано это совсем не с Qt, a с медлительностью продвинутого дизассемблирования тяжёлых бинарников.
VK>Сейчас железо, конечно, намного быстрее. Но циклы то все равно тратятся впустую, просто это теперь не так заметно.
А ещё на Qt сделан, на минуточку, ГУЙ бортового компа Теслы.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
vaa>>скорости старта примерно одинаковые ~ 1.5 sec (окошко с одним контролом и после открытия закрытие, мерял time в релизе)
НС>Читал?
Нет)) похоже на анекдот, висту не используй, используй хп.
все упирается в скорость загрузки библиотек.
даже после дополнительной перекомпиляции сборка в которой находится одна используемая функция должна загрузится полностью в память.
ахилесова пята дотнета.
тут рулят ЯП которые изначально умели импортировать отдельные функции.
не утверждаю, но вроде так умел еще turbo pascal for dos из-за чего получались очень быстрые экзешники.
1.5 сек на самом деле уже норм(речь о корке), для сравнения взял ракет(под капотом кстати плюсовые wx)
все гораздо медленнее при том что бинарник ракета 20 а ФП 28 метров.
Т.е. ЯП однозначно вносит свой вклад в производительность продукта.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, vaa, Вы писали:
vaa>>Перечислил некоторые. vaa>>В СЯП больше низкоуровневых конструкций, меньше абстракций между железом и языком. vaa>>как правило ручное управление памятью.
НС>Почему для тебя в контексте гуя это важно?
хочу понять можно ли с нормальной скоростью разрабатывать(без боли) ричапп на СЯП. vaa>>go/dlang как раз за наличие GC ругают.
НС>Но D ты перечислил.
Ну вот эта критика и останавливает, хотя по удобству программирования это гибрид шарпа и питона.
а по гибкости еще круче. но помимо ГЦ у него его один минус маргинальность. а мы сейчас пытаемся понять на чем реально люди пишут гуй.
пока я так понял для кроссплатформы реально используется только лазарус(object pascal) и кьютэ(C++).
остальное экзотика для самураев.
Здравствуйте, vaa, Вы писали:
vaa>>>В СЯП больше низкоуровневых конструкций, меньше абстракций между железом и языком. vaa>>>как правило ручное управление памятью. НС>>Почему для тебя в контексте гуя это важно? vaa>хочу понять можно ли с нормальной скоростью разрабатывать(без боли) ричапп на СЯП.
Ты ответил не на тот вопрос, который я спрашивал.
vaa>>>go/dlang как раз за наличие GC ругают. НС>>Но D ты перечислил. vaa>Ну вот эта критика и останавливает,
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>Почему для тебя в контексте гуя это важно? НС>Ты ответил не на тот вопрос, который я спрашивал.
Хочется максимального перформанса от гуя. нытье конеш но быстрый старт дорогого стоит.
vaa>>>>go/dlang как раз за наличие GC ругают. НС>>>Но D ты перечислил. vaa>>Ну вот эта критика и останавливает,
НС>Критика? Объективные причины есть?
Эксперты пишут сборщик мусора тормозной в ди.
возможность его отключения лишает всех плюшек ди.
насчет го не скажу.
Здравствуйте, CreatorCray, Вы писали:
S>> Как люди воспримут? CC>А куда они денутся? Наёмный работник делает то, что ему сказали, получает за это деньги. CC>Не нравится — не нанимайся
Как правило, начав проект 100% с нуля без внешних зависимостей, чудовищный шанс напороться на проблемы с наймом, когда понадобится команда.
Далеко не любой разработчик сходу влезет в код, где всё своё. И дело не в желании, а в квалификации, т.е. вопрос пальцем не заткнешь.
А раз так, то платить придется столько, сколько захотят, и не факт, что сможешь это потянуть.
Здравствуйте, vaa, Вы писали:
НС>>>>Почему для тебя в контексте гуя это важно? НС>>Ты ответил не на тот вопрос, который я спрашивал. vaa>Хочется максимального перформанса от гуя.
Ты же понимаешь, что минимально распознаваемое время реакции гуя это очень большая величина? И, при должном внимании, даже на питоне получаются практически идеально быстрые приложения. Надо просто не лениться и делать потенциально длительные (> 100 мс) операции асинхронными. МС в свое время в сервелате вообще убрал почти весь синхронный IO и это крайне благотворно повлияло на отзывчивость сервелатных приложений.
vaa> нытье конеш но быстрый старт дорогого стоит.
Т.е. тебя волнует только стартап? Это лечится способами куда менее радикальными, нежели полная смена платформы. Это, конечно, если тебе ехать, а не шашечки.
vaa>>>Ну вот эта критика и останавливает, НС>>Критика? Объективные причины есть? vaa>Эксперты пишут сборщик мусора тормозной в ди.
Здравствуйте, Pauel, Вы писали:
P>Как правило, начав проект 100% с нуля без внешних зависимостей, чудовищный шанс напороться на проблемы с наймом, когда понадобится команда.
Куда вероятнее то, что все закончится напедаливанием очередного мегафреймворка, а полезный код так никто и не напишет. Почему то именно гуй этим особо раньше страдал, пока весь десктоп вместе со своим гуем не начал тухнуть.
Здравствуйте, vaa, Вы писали:
vaa>Кто-то пишет GUI (настольные приложения) на системных ЯП? vaa>Т.е. не просто диалог простенький с чек-боксами , а приличное приложение, например для работы с БД, vaa>т.е. с датагридами и т.п. vaa>Ели да, какие? паскаль, си, ди, зиг, раст, плюсы?
А вы хотите начать проект или продолжать его в течение 5-10-15 лет?
Посмотрите на линукс — проектов начинают много, на чем угодно, даже на жээсе. Правда среднее время жизни проекта такое ощущение что пару лет. Только малая часть вырастает до чего то более-менее стабильного.
Потому я бы отталкивался от платформы, на которой пишет довольно большое число людей. И это точно не системный ЯП. В противном случае надо ожидать тяжелый кризис спустя год-два-три после чего проект будет жить только в репозитории "последний релиз 5 лет назад".
Здравствуйте, Shmj, Вы писали:
S>Бывало ли в вашей практике, что компания завязывала людей на собственные разработки, которые больше нигде не используются?
Такое норма в компаниях разной степени продуктовости. Главное — баланс и стоимость мейнтенанса. Упороться можно и на внешних компонентах. Здесь, правда, протухание идет намного быстрее, потому заметнее и бороться с этим начинают пораньше.
В любом случае, чем больше доля собственного кода, тем сложнее найти кандидата, т.к. это автоматически задирает планку требуемой квалификации.
До кучи — есть риск для кандидата "эксперт в самописных вещах", что снова придется компенсировать деньгами.
Какой ожидаемый цикл жизни, год, два, десять? На коротких проектах лучше брать внешние пакеты. На длинных — стартовать лучше на внешних постепенно или мигрируя на новые, или заменяя своим.
Здравствуйте, Pauel, Вы писали:
P>В любом случае, чем больше доля собственного кода, тем сложнее найти кандидата, т.к. это автоматически задирает планку требуемой квалификации.
Либо наоборот, снижает. Если компания использует внутренний фреймворк X, специалистов по которому на рынке нет от слова совсем, то бесполезно искать кандидатов уровня senior со знанием X. Их не существует. Посему можно брать junior-ов или middle-ов и погружать их в X.
Здравствуйте, Shmj, Вы писали:
S>Бывало ли в вашей практике, что компания завязывала людей на собственные разработки, которые больше нигде не используются?
Лет 15 назад довелось общаться с человеком из магнитогорской компании "Компас Плюс". Они значительную часть своего софта тогда писали с использованием собственной системы визуального программирования "Флора". Которая была написана ими самими и больше нигде и никем не использовалась.
Соответственно, куча разработчиков "Компас Плюс" пользовалась только "Флорой" и была завязана только на "Флору". По словам этого человека компании такое положение дел было выгодно -- они брали студентов местных ВУЗов, обучали их "Флоре" и не опасались текучки кадров, т.к. податься потом с опытом во "Флоре" было некуда.
Не знаю, как у них дела обстоят сейчас, но тогда "Компас Плюс" чувствовал себя более чем нормально.
Здравствуйте, so5team, Вы писали:
S>Соответственно, куча разработчиков "Компас Плюс" пользовалась только "Флорой" и была завязана только на "Флору". По словам этого человека компании такое положение дел было выгодно -- они брали студентов местных ВУЗов, обучали их "Флоре" и не опасались текучки кадров, т.к. податься потом с опытом во "Флоре" было некуда.
Это выгодно для работодателя, только если он сможет вложить средства в развитие студента с нуля. Это явно не мелкий и средний бизнес.
Работнику не выгодно почти никогда — либо нужно быть наивным юношей, либо же от безвыходности.
НС>Т.е. тебя волнует только стартап? Это лечится способами куда менее радикальными, нежели полная смена платформы. Это, конечно, если тебе ехать, а не шашечки.
встречают по одежке )) (опять нытье)
НС>Это точно критично для гуя?
Здравствуйте, Shmj, Вы писали:
S>Работнику не выгодно почти никогда — либо нужно быть наивным юношей, либо же от безвыходности.
Ну, внутренние технологии того же Гугла или Яндекса (да, это крупные компании) временами выходят в свет и становятся стандартными. Так что иногда есть смысл поучаствовать в чём-то подобном
, а приличное приложение, например для работы с БД,
