а чем все-таки отличаются С и С++?

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

 

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

 

dZentle_man
использование фраймворка не освобождает от знания происходящих процессов, а просто помогает тем, кто их знает )
ничего плохого в использовании промышленных фреймворков нет

 

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

 

dZentle_man
работал с CodeBlocks и на винде и на никсах, она на твоём фреймворке. ни каких притензий к скорости

 

Продолжайте, я только что вернулся с очередной порцией попкорна.

 

Да, действительно работает хорошо, очень и очень неплохой фреймворк. Но в принципе что простительно для IDE, то не всегда простительно для других программ, для моей в принципе терпимо, но я хотел бы большего.

 

dZentle_man

а мне кажется, что значёк моей аськи не достаточно зелёный, я хотел бы зеленее )

 

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

 

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

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

 

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

Да не говорю. Он нужен, особенно для случая когда доступа к проге нет, а к ее базе данных нужно доступиться.

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

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

Это в идеале) В реале разница между платформами может оказаться настолько существенной, что проще написать и поддерживать разные версии.

 

dZentle_man
> А причем тут командная строка и веб-интерфейс?
у меня командная строка чуть ли не для каждого модуля. вот есть антивирусный сканер. в нем есть модуль (в приплюснутой терминологии -- класс) zlib для расжатия zlib/gzip-потоков (даже битых). и этот модуль имеет самостоятельную ценность даже вне антивиря. и сам антивирь тоже обернут в командую строку, хотя с ней работаю наверное я один остальные через гуи.

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

>Если командная строка для управления прогой, то в моей задаче она излишня,
может это ваша прога излишняя? даже у фотошопа есть командная строка не говря уже за Irfan Viewer и прочие кошерные программы.

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


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

> Линь меня интересует в последнюю очередь.
вот... а была бы командная строка -- просто пересобрал под линем и все

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

> Это в идеале) В реале разница между платформами может
> оказаться настолько существенной, что проще написать и поддерживать разные версии.
разница между платформами не имеет ничего общего с отделем мух от котлет, т.е. логики работы от интерфейса. причем не только интерфейса пользователя, но и АПИ. потому как есть у вас хороший АПИ то любой компонент вашей программы вы можете вытащить и вставить в другую программу. то есть логика работы должна быть реализована как библиотека. а эта библиотека в свою очередь состоит из других библиотек. допустим, вам потребовалось по ходу дела работать в массивами больше 4 гб на 32 операционке и вы создали свою реализацию разряженных масивов неограниченной разрядности. как легко понять -- эти массивы очень ценны даже вне рамок программы. с другой стороны, если апи массивов хорошо проработан, то вы можете выкинуть свой лисапед и взять любой готовый

а интерфейс... ну это все-таки что-то очень посторонее... к тому же интерфейс вам напишут и за $20k в год. а за написание логики берут хотя бы $90k, а если эта логика к тому же и нетриваильная, то - $150k. вопрос - если программст, работающий за $150k потратит хотя бы 30% своего времени на написание интерфейса -- сколько потеряет компания?

 

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

Ну вот видите) Даже среди прожженных энтузиастов и не последних людей в программировании бескомпромиссных любителей командной строки не так уж и много

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

Может быть и так

куда мне со свиным рылом в калашный ряд

Да, Irfan Viewer прекрасен чуть менее, чем полностью) Но я даже не подозревал что у него еще и командлайн есть)

Я думаю где-то на треть проги. Это если дублировать весь функционал гуя. А если не дублировать, то не совсем понятно что нужно реализовать и почему нельзя без этого жить.

Да, вы правы. С тестированием пока никак.

Мысль интересная, но сначала нужно реализовать десктопную и мобильную)

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

Вот и я про то же) А куда денешься - надо же с чего то начинать.

Ну я пока еще не вполне раскурил этот вопрос, поэтому сам еще не убедился) Но склонен вам верить)

Поэтому пока и не тороплюсь рефабришить код, потому что идеи по перепроектированию все множатся и множатся, и одна лучше другой)

Если решать задачу в лоб и принять срок написания всей проги в 1 год, то 150*0,3-20=25($k) Но мы то понимаем, что то, что напишет программист получающий 150к в год - может сильно отличаться качеством от программиста за 20к, причем наверняка часто сравнение будет не в пользу последнего) А какими убытками может грозить не очень качественный код в будущем, а то и настоящем, для компании... Короче математика не очень сильна при расчете выгоды компании в программерском деле)

 

А в чём разница между "научить" и "объяснить"? В том, что "научить" -- это практика, а "объяснить" -- теория? Тогда не надо объяснять, теорию я в состоянии найти в гугле.

Если из 2k строк программы выкинуть код относящийся к организации гуя, то там ничего не останется. Организация же гуя нисколько не показательна

Это уже озвучили до Вас. Я повторюсь: мне неинтересна теория. Я учитался ею. Но поскольку я не видел ни одного хорошего примера применения этой теории на практике, я делаю вывод, что эта теория так и осталась теорией.

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

 

Ага понятно почему в природе не существует нормальных реализаций гуев )

Ответ - компания приобретёт нормально реализованный интерфейс который легко поддерживать/переносить/расширять функционал, но при этом без невменяемых накладных расходов фраймеворков превращающих 1к функционала в 10М х.з. чего.

ЗЫ: А если она ещё наконец сделает такой нормально реализованный набор интерфейсных функций общедоступным, то будет вообще супер Только гляжу "реальным пацанам" это неинтересно и они предпочитают довольствоваться неквалифицированными поделками.

 

dZentle_man
признай, что ты просрал в топике и закроем)

 

Чесна говоря некогда вступать в дискуссию, но не согласен что просрал, тем более что и не срал вовсе) Топик был создан с целью получить представление почему крутые спецы сильно разграничивают С и С++, а вовсе не для экспансии собственного учения о правильном кодировании, как может показаться не очень вдумчивому читателю) В общем я бы не закрывал, может со временем отпишется еще пара умных и че нить дельное скажут) Ну а мне, повторюсь, пока некогда тут висеть)

 

dZentle_man

Потому что это сильно разные языки Ну вот как тебе на пальцах рассказать, что Bugatti Veyron - это сильно круче, чем Mercedes SLK, если ты и то и другое знаешь только по картинкам?

 

Не видел ни одного человека из этой группы. Покажешь?

 

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

итд. много чего.
так что не надейтесь, что сможете обойтись чемто одним и не тратьте времени на поиски наилучшего.