Виртуальное Программирование Реальных Задач (ВПРЗ)

[dobegin]

Предлагаю провести эксперимент по созданию реально работающей программы.
Обсуждаем задачу. Пишем тесты. Кодим все вместе. Исходники и результат - всё общее.
Используем на благо всех живых существ.

[DOKA]

Предлагаю провести эксперимент по созданию реально работающей программы.

Я уже не раз проводил эксперимент, и могу сказать, коллега, что реально работающую программу создать возможно.

Идея интересная, но больше для студентов. Хотя, если будет интересно, и вдруг(!) у меня появится время, то может и поучаствовал бы.

[dobegin]

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

[Ega23]

Предлагаю провести эксперимент по созданию реально работающей программы.
Обсуждаем задачу. Пишем тесты. Кодим все вместе. Исходники и результат - всё общее.
Используем на благо всех живых существ.

Хочешь сделать что-то вечное умное и доброе? Не вопрос, цепляйся к ОС-коммьюнити (Postgres, например) и вперёд и с песнями. Если обладаешь нужной квалификацией, разумеется. Даже денег заработаешь.
Но лично меня терзают смутные сомнения.

[migel32]

Предлагаю в качестве среды програмирования использовать кроссплатформенный фреймворк QT.

[Ega23]

Предлагаю в качестве среды програмирования использовать кроссплатформенный фреймворк QT.

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

[migel32]

В том то вся и штука если выбрать Qt как средство разработки, то выбирать платформу уже не придётся.

[DOKA]

В том то вся и штука если выбрать Qt как средство разработки, то выбирать платформу уже не придётся.

ОК. Давайте запрограммируем какой-нибудь микроконтроллер на Qt. Или драйвер напишем. Или сайт.

[Ega23]

В том то вся и штука если выбрать Qt как средство разработки, то выбирать платформу уже не придётся.

Да-да-да, абсолютная совместимость на любой платформе без доработки напильником и унылых бесконечных ifdef-ifndef.
Скажу по секрету, для задачи расчёта определителя матрицы достаточно взять MS Excel (для MS-ненавистников - опенофиновский calc), Qt будет как из пушки по воробьям.

[Ega23]

ОК. Давайте запрограммируем какой-нибудь микроконтроллер на Qt. Или драйвер напишем. Или сайт.

Сайт, кстати, можно, CGI никто не отменял. Отвратительно, правда, будет и не оптимально. Но можно.

[migel32]

В том то вся и штука если выбрать Qt как средство разработки, то выбирать платформу уже не придётся.

ОК. Давайте запрограммируем какой-нибудь микроконтроллер на Qt. Или драйвер напишем. Или сайт.

Qt ето просто сборник c++ библиотек....
можеш использовать Qt вместе со стандартными функциями C++, WinAPI, MFC и т.д и т.п.... можеш даже и другие библы подключать, такие как boost и т.п.
Можеш использовать ассемблерные вставки.

[Ega23]

Qt ето просто сборник c++ библиотек....

Вообще-то не совсем.

[DOKA]

можеш

"МожешЬ"

Qt ето просто сборник c++ библиотек....

Ну, а коли так, зачем тогда предлагать использовать какую-то библиотеку, не зная задачи? Может нам она и не пригодится, может будет неоптимальной. В действительности можно написать что угодно применив какое угодно средство (например, драйвер, который будет работать только при наличии Java), но нафига???.

[jam]

Кхм... QT это просто ГУЙ-ня, ну плюс приблуды некоторые, вобщем рассматривать ее в качестве ядра довольно недальновидно. сам сиплюсплюс является независимым от платформы ЯП, напишите сначала ядро, а уж потом к нему ГУИ разработать под конкретную ОСь как 2 пальца об асфальт.

[Ega23]

сам сиплюсплюс является независимым от платформы ЯП, напишите сначала ядро, а уж потом к нему ГУИ разработать под конкретную ОСь как 2 пальца об асфальт.

1. Любой язык является независимым от платформы.
2. Практика показывает, что делать надо всё-таки комплексно, какой-то позорный гуй начинать вместе с ядром делать. По крайней мере станет ясно, что от ядра ожидать, свистелки-перделки действительно позже приделываются.

[jam]

1. Любой язык является независимым от платформы.
2. Практика показывает, что делать надо всё-таки комплексно, какой-то позорный гуй начинать вместе с ядром делать. По крайней мере станет ясно, что от ядра ожидать, свистелки-перделки действительно позже приделываются.

1. Скажем тот же Делфи (а он с некоторых пор позиционируется как ЯП) от ОСи ой как зависит.
2. Если разбить правильно задачу на уровни логики (данные/бизнес/ГУИ) то ГУИ можно приделать абсолютно любой, каждый под своей платформой.
PS: а вообще зацикливание на кроссплатформенности может завести очень далеко и надолго.

[Ega23]

1. Скажем тот же Делфи (а он с некоторых пор позиционируется как ЯП) от ОСи ой как зависит.

Не зависит он от оси. От оси зависит компилятор (интерпретатор), но не сам язык. Ты можешь текст программы на сферическом Тьюринг-полном языке в вакууме на бумажке ручкой записать.

2. Если разбить правильно задачу на уровни логики (данные/бизнес/ГУИ) то ГУИ можно приделать абсолютно любой, каждый под своей платформой.

Ни разу не встречал полностью детализированного ТЗ, которое было написано и согласовано с заказчиком с первого раза и потом не появлялись перлы "Ой, а я не это имел ввиду" или "Ой, а мы тут ещё одну штуку вставить забыли" и т.п.

PS: а вообще зацикливание на кроссплатформенности может завести очень далеко и надолго.

Это да, с этим согласен.

[DOKA]

2. Если разбить правильно задачу на уровни логики (данные/бизнес/ГУИ) то ГУИ можно приделать абсолютно любой, каждый под своей платформой.
PS: а вообще зацикливание на кроссплатформенности может завести очень далеко и надолго.

Иногда это (полное MVC) либо невозможно, либо настолько сложно, что нет смысла заморачиваться. Пример: ГУИ с очень сложной логикой, когда вдруг(!) начинает требоваться чтобы объект из одной группы объектов зависел от конкретного инстанса другого объекта (например из anotherPackage.someObject.someArray[42]) на первый взгляд не зависящего от него. Ну захотел так заказчик, к примеру, куда деваться.

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

Написание ГУИ может стать сложной задачей и под одну платформу, а поддерживать кучу оболочек - это нееее, обычно стоит отказаться от такого счастья.

[jam]

Не зависит он от оси. От оси зависит компилятор (интерпретатор), но не сам язык. Ты можешь текст программы на сферическом Тьюринг-полном языке в вакууме на бумажке ручкой записать.

В понятие "Делфи" вкладывается не столько язык Паскаль/Объект/Паскаль, сколько сама ВЦЛ, а она то как раз и является ничем иным как оберткой над WinApi.

Ни разу не встречал полностью детализированного ТЗ, которое было написано и согласовано с заказчиком с первого раза и потом не появлялись перлы "Ой, а я не это имел ввиду" или "Ой, а мы тут ещё одну штуку вставить забыли" и т.п.

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

[Ega23]

В понятие "Делфи" вкладывается не столько язык Паскаль/Объект/Паскаль, сколько сама ВЦЛ, а она то как раз и является ничем иным как оберткой над WinApi.

Delphi (как язык) - наследник Object Pascal, содержит с полсотни ключевых слов и где-то столько же операторов.
Delphi (как IDE) - ну тут кому как, кому-то нравится, кому-то нет.
Delphi (как VCL) - это на много лет изучения, тут только вдумчивое чтение умных книг и исходников.

Ну а то, что VCL это обёртка над WinAPI - это не совсем так, Kilyx никто не отменял, ifdef-ов там в коде дофига и больше.

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

Сколько раз у тебя было, что ты получал ТЗ, сразу полностью оформленное и ни разу не изменявшееся по ходу разработки (речь про проекты сроком от 3-х месяцев)? Я, пожалуй, ни разу.

[jam]

Сколько раз у тебя было, что ты получал ТЗ, сразу полностью оформленное и ни разу не изменявшееся по ходу разработки (речь про проекты сроком от 3-х месяцев)? Я, пожалуй, ни разу.

Во всех долгосрочных проектах (4 шт. в среднем 7-9 мес. на проект) я "сам себе режиссер", т.е. заказчик озвучивает начальную точку отсчета и окончательный результат, а я уже разрабатываю ТЗ и пляшу от него.

[Ega23]

Во всех долгосрочных проектах (4 шт. в среднем 7-9 мес. на проект) я "сам себе режиссер", т.е. заказчик озвучивает начальную точку отсчета и окончательный результат, а я уже разрабатываю ТЗ и пляшу от него.

И ни разу не получалось, что на половине срока заказчик ВНЕЗАПНО вспоминал, что он тебе ещё одну ма-а-аленькую детальку не указал, но у тебя из-за этого приходится всю БД и всё ядро перестраивать?
Ну тогда тебе повезло, я с таким сталкивался неоднократно.

[jam]

Во всех долгосрочных проектах (4 шт. в среднем 7-9 мес. на проект) я "сам себе режиссер", т.е. заказчик озвучивает начальную точку отсчета и окончательный результат, а я уже разрабатываю ТЗ и пляшу от него.

И ни разу не получалось, что на половине срока заказчик ВНЕЗАПНО вспоминал, что он тебе ещё одну ма-а-аленькую детальку не указал, но у тебя из-за этого приходится всю БД и всё ядро перестраивать?
Ну тогда тебе повезло, я с таким сталкивался неоднократно.

Было один раз, из однопоточки на многопоточку захотели переделать (проект правда скромный был, на 70-80 часов), ну так я с него за хотелку взял как за новый проект - по сути так оно и получилось.

[Ega23]

Было один раз, из однопоточки на многопоточку захотели переделать (проект правда скромный был, на 70-80 часов), ну так я с него за хотелку взял как за новый проект - по сути так оно и получилось.

А у меня только один раз было всё чётко. Так что я весьма подозрительно отношусь к фразам "надо заранее всё продумать, спроектировать ядро, а ГУЙ уже потом сам привернётся". Практика показывает, что не всё ладно в Датском королевстве.

[dbalka]

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