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

Возникли вопросы:
1) Где раздобыть достаточно материала на тему разработки АС и т.п.
2) Что Вы хотите «видеть» в этой программе???

Видели-те, уважаемый ЕХЕ, Вы не программист, Вы - кодер.

Я охотно верю что Вы отлично овладели ООП, С++, СОM/DCOM, .NET, и прочим, но все это - малоквалифицированное ремесло.
Я даже охотно верю, что Вы с большим презрением относитесь к Дельфи и т.п. средствам RAD.

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

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

Поэтому наилушим советом Вам, я думаю будет скооперирроваться с кем-то, кто владеет всеми этими вопросами, а Вы будете просто реализовывать задуманное им в коде.

Alex Torres



У Вас несколько странное представление о программировании. Программирование - это такая же сложная профессия, как и любая другая инженерная профессия. У нас в компании, например, нет даже такой должности "программист". У нас все они - инженеры. И никакое это не ремесло. Это ближе к искусству.

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

И еще: нам удается вырастить хороших программистов из студентов-старшекурсников примерно года за два. Примерно в те же сроки они научаются базовым научным знаниям, необходимым для того, чтобы создавать технологические компоненты программ. Разработку подсистем мы доверяем людям, которые имеют опыт работы в компании не менее 4-5 лет. Сложность обучения науке и программированию примерно одинакова.
\n\n(Добавление)
EXE

Я предлагаю Вам сузить задачу. Сделайте программу просто для дипломной работы. Ее можно сделать весьма формально, не опираясь на практику, пользуясь формулами из учебников (в инете есть целые библиотеки остканированных книг на эту тему в формате DjVu -- посмотрите раздел форума "Литература", там есть ссылки). Никто не станет на основе Вашей программы создавать реальные акустические системы, поэтому Вы ничем не рискуете. Более того, Вы можете попытаться настроить "подгоночные параметры" своей программы под то, что выдают существующие известные приложения. Это программа-минимум. И на мой взгляд -- программа оптимум.

Если Вам хочется бОльшего, то без собственноручного изготовления колонок, и не одной, Вам не обойтись. Кроме формул, все программы рассчета колонок содержат массу эвристических знаний (выраженных в виде ограничений примениости алгоритмов рассчета для конкретных случаев, разумных диапазонов параметров, учета конструктивных особенностей и т.д.), без которых Ваша программа вряд ли будет мало-мальски полезной. Наработка всех этих вещей -- это не один месяц работы, чтения всех и всевозможных источников и т.д. Можно попробовать найти опытного человека и помучить его. Но толку? Бесплатная программа не принесет денег ни Вам, ни ему. Времени отнимет море. Вряд ли кто будет ею пользоваться -- есть известные и проверенные программы, которыми люди пользуются, да и те содержат массу недостатков. И что самое плохое -- Вы напишете программу, выложите в Инет и забудете про нее. И она так и умрет, не созрев до нужного уровня. А чтобы поддерживать такую программу, нужно постоянно тратить усилия и время. Первые же пользователи будут посылать Вам сообщения об ошибках, Вам придется разбираться с ошибками расчетов, с непонятками, возможно, даже ездить к пользователям, чтобы вместе выяснить, какую важную вещь Вы не учли в своей программе, и с которой на практике столкнулся пользователь. Вы готовы на это? Если нет, то и не надо браться.

Вы путаете понятия "программист" и "кодер".




Вполне возможно, но это "программисты", а основная масса "кодеров" в мире - не "студенты за два года", а после 3-6 месячных "курсов переквалификации в программисты из погонщиков слонов"



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

Нравится это или не нравится - но это сегодняшняя реальность.
\n\n(Добавление)
С остальным, по поводу программы расчета АС - согласен

Alex Torres

По моему, EXE как раз это и пытается сделать. Не желаете внести свою лепту? Кроме шуток. Вы и другие спецы критиковали существующие проги. Думаю, стоит приветствовать такие попытки.

Помоему, он уже куда-то пропал.



Хотел бы, но заниматься этим серьезно - у меня нет на это времени.
На конкретные вопросы, если смогу - отвечу.

Alex Torres



Так ведь EXE вроде себя программистом назвал. А Вы его кодером обозвали. Зачем обзываться?



Кое-кого интересует. А кого не интересует, те рано или поздно будут out of business. У нас, например, люди в отделе разработки получают повышение в зарплате и в позиции только после прохождения "аттестации", в которой основная часть -- проверка качества кода, который написал программист с точки зрения его изящества, разумности, внятности и т.д. Дело в том, что уже даже в России программисты начинают стоить довольно дорого. Если систематически сливать деньги и получать "мусор" на выходе, то потом начинаются проблемы с сопровождением этого мусора. Которые обходятся в разы дороже, нежели сам мусор.

Ну это зависит вовсе не от изящества кода.
Какой изящный код был у полуоси и БеОС? И где они ?
Там же, где и большинство программистов на ассемблерах.



Про Россию не знаю, а в других местах, после того как мыльный пузырь дот.комов лопнул - высокие з/п программистов наоборот снизились до среднеинженерного уровня, и это правильно.
И "изящный" код - если кого и интересует, то только при написании не прикладных а системных задач (драйверы, реалтайм и т.п.)




Зачем же "получать мусор на выходе"? Не приписывайте мне того, чего я не говорил!



Разумеется, но для этого существуют определенные стандарты по оформлению кода и вообще стандарты и сертификации
предприятий (ISO-900*).

Alex Torres

Мы сейчас уйдем в глухой оффтоп на эту тему. Но давайте поспорим немного.



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


Программирование на ассемблере было когда-то вынужденной мерой. Нельзя было сделать MS-DOS или MacOS не на ассемблере. Первая версия MacOS занимала всего 128Кб в ROM, и в эту память надо было втиснуть всю графическую и оконную библиотеку, файловую систему, драйверы и т.д. Компиляторы в те времена не умели делать оптимальный код, на их объектный код нельзя было смотреть без слез. В наши времена избытка ресурсов на ассемблере программируют только очень критический код и микрокод. Со всем остальным оптимизирующие компиляторы справляются лучше человека. Поэтому и почили в бозе большинство программистов на ассемблере. И никакого отношения этот процесс к качеству написания кода не имел.

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




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



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

"Зависит от".

В моей практике, среди десятков процессоров, с основной массой которых я начинал с ассемблера, есть например один - для котрого я сразу писал на Си, и устройство его команд знал весьма поверхностно.
Это Atmel AVR.
И "узнал" я его систему команд чуть-чуть углубленее, позже, когда в одном проекте возникла необходимость в "сильно реалтаймовом кусочке" сделать в Си-коде ассемблерную вставку.




Знаете, это опять же сильно "зависит от".

Если, к примеру, программа на Си для крохотного ST7Lite09 влазит в его 1.4кб памяти ь и успевает по скорости - никого не волнует занимает она 1.3кб или 0.8кб.
Вот ежели не влазит - тогда надо смотреть что лучше, взять процессор с большей памятью и написать программу на Си за неделю, или оставить этот проц, и месяц заниматься "изысками" на ассемблере.

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