Программирование - это просто
- Автор темы Жадный КаБан
- Дата начала
CoderA
Местный
Microsoft Robotics
Microsoft Robotics products and services enable academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware.
http://msdn.microsoft.com/ru-ru/robotics/d...28en-us%29.aspx
http://www.techdays.ru/category/17/69.html
Microsoft Robotics products and services enable academic, hobbyist and commercial developers to easily create robotics applications across a wide variety of hardware.
http://msdn.microsoft.com/ru-ru/robotics/d...28en-us%29.aspx
http://www.techdays.ru/category/17/69.html
Думаю
Пользователь
Опубликован январский рейтинг языков программирования
Язык программирования Go, разработанный в Google, показывает небывалый рост популярности. Утверждается, что он поддерживает многопоточное программирование и параллелизм вычислений, позволяя эффективно нагружать современные многоядерные процессоры. Не отстает и Apple Objective-C, получивший впечатляющую поддержку разработчиков.
Ссылка
Язык программирования Go, разработанный в Google, показывает небывалый рост популярности. Утверждается, что он поддерживает многопоточное программирование и параллелизм вычислений, позволяя эффективно нагружать современные многоядерные процессоры. Не отстает и Apple Objective-C, получивший впечатляющую поддержку разработчиков.
Ссылка
Думаю
Пользователь
Справедливости ради замечу, что Go в представленном рейтинге замыкает чертову дюжину, а лидеры все те же - java, c, c++...
sami
Местный
У гугля на этот счет, кстати, другое мнение.
Но работать-то надо головой, а не глядя на рейтинги. У go довольно специфичная ниша при практически полном отсутствии библиотек. Интероперабельность и совместимость сильно хромают. Бенчмарки сильно далеки от заявленных. Будем надеяться, что это пока.
Я полагаю, что эти рейтинги - результат пиара, и вряд ли мы увидим вскоре серьезные проекты на сыром языке. Вот через годик - вполне реально. Народ походу просто активно щупает, обсуждает и т.п.
На том же rsdn.ru активность по поводу go сошла на нет с месяц назад или более.
интересно, почему C популярней C++?
sami
Местный
C намного проще чем C++, и отсюда следствия:
- Порог вхождения в язык C гораздо ниже, чем у C++. Это означает, что довольно успешно на нем программировать могут не только специализированные программисты, но так же и физики, химики, инженеры и люди других научно-технических специальностей (и не только).
- Компиляторы C несравнимо проще компиляторов C++. Это означает, что более-менее совместимый со стандартом компилятор C можно налабать для любого устройства, и даже для регистровых машин (как это делал Луговский), в то время как разработка компилятора C++ дело очень дорогое и долгое.
Вообще в рамках языка C гораздо проще делать переносимые программы, чем в рамках C++. Я конечно видел переносимые программы на C++, но аспекту переносимости в них было уделено внимания едва ли не больше чем всему остальному. В общем, без высокоуровневых переносимых библиотек это очень дорого.
Непоследнее место в аспекте переносимости кода занимает размер скомпилированного кода. У C++ он значительно больше, потому он с опаской используется при программировании устройств с ограниченными ресурсами. - У языка C беспрецедентная совместимость. Код, написанный на C легче использовать из других языков программирования. В свою очередь, разработчики других языков и платформ стараются делать возможность вызывать код, написанный на этих языках из C. Таким образом, C играет роль универсального клея.
Touareg
to kalon epieikes
sami
Местный
Тем не менее, кое-что из ООП просочилось и в C. Я имею в виду моделирование виртуальных таблиц с помощью структур, состоящих из полей типа функциональных указателей, что собственно приводит к возможности использования ad-hoc полиморфизма, своего рода абстракцией и инкапсуляцией в C. Можно конечно и наследование смоделировать с помощью аггрегации, но от наследования в ООП как раз больше всего проблем.
Что же касается принципов ОО дизайна, заложенных еще Аланом Кеем в Smalltalk-е:
- так этого никто не отменял. Многи функциональщики используют эти принципы для проектирования сложных систем.
Разочарование приходит как раз от буквальной интерпретации ООП, где "все является объектом" и "единая иерархия наследования" и т.п. В свою очередь иметь абстрактный поток данных, и уметь читать данные из любого источника (файл, кусок памяти, сокет) - это отличная идея, которая широко используется и в C тоже.
sami как всегда на высоте. По делу и без воды. И без тык-мык.
Почему я так не умею? :lol:
C++ погряз и запутался в своих собственных концепциях. Код C++ стал каким-то безобразием.
В погоне за упрощением, утопили ребёнка - поддержка кода C++ стала очень трудоёмкой.
Много ещё можно сказать.
C++ - это неплохо, но нужно хорошенько подумать прежде чем выбрать его для своего нового проекта.
Почему я так не умею? :lol:
Самое смешное - это доступно было и ранее. Кто мешает вам соответствующую функцию в свою библиотеку написать.
C++ погряз и запутался в своих собственных концепциях. Код C++ стал каким-то безобразием.
В погоне за упрощением, утопили ребёнка - поддержка кода C++ стала очень трудоёмкой.
Много ещё можно сказать.
C++ - это неплохо, но нужно хорошенько подумать прежде чем выбрать его для своего нового проекта.
sami
Местный
Это ирония, или и правду по делу? Нет, честно не понял и вполне допускаю за собой воду и не по делу.
Ранее чего и соответствющую чему?
Допустим, я использую библиотеку по работе с картинками. Она умеет читать картинки из файла, но не умеет из почтового вложения. Кто разработчику библиотеки мешал написать соответствующую функцию?
Я говорил о том, что введя абстракцию потока данных, разработчик библиотеки может сделать свою библиотеку более гибкой. Это типичный полиморфизм из ООП, явная поддержка которого не была заложена в C.
Я полагаю, что это пришло из ООП, хотя и было доступно в C ранее.
Полностью поддерживаю. Могу лишь добавить, что останавливаясь на C, тоже нужно хорошо подумать.
Нет.
Не, не.
Оставим картинки в покое.
Я про то, что объекты и наследование можно реализовать в своём собственном проекте на чистом С, и это не очень сложно.
sami, на самом деле, мы говорим о вещах которые мало кому понятны.
Я уверен что большинство понимает что такое указатель на объект (функцию).
Но с введением понятия указатель на указатель - наша аудитория уменьшается раза в два.
А если заговорить о многомерном динамическом массиве указателей на массивы указателей?
Совсем мало народу осталось в аудитории.
Сам C++ написан на чистом C.
Концепция ООП была революционной, структурное программирование себя изжило т.к. в тот момент производительность процессоров ещё не была избыточной (но пользователю уже хотелось новых интерфейсов) а опыта создания таких программ ни у кого не было.
Собственно, появление производительных процессоров и идея создания интерактивных интерфейсов и привела с появлению C++
Я уверен что большинство понимает что такое указатель на объект (функцию).
Но с введением понятия указатель на указатель - наша аудитория уменьшается раза в два.
А если заговорить о многомерном динамическом массиве указателей на массивы указателей?
Совсем мало народу осталось в аудитории.
Сам C++ написан на чистом C.
Концепция ООП была революционной, структурное программирование себя изжило т.к. в тот момент производительность процессоров ещё не была избыточной (но пользователю уже хотелось новых интерфейсов) а опыта создания таких программ ни у кого не было.
Собственно, появление производительных процессоров и идея создания интерактивных интерфейсов и привела с появлению C++
Хочу сказать о печальном опыте применения С++ в одном из проектов в большом коллективе. Сначала казалось, что все мы только выйграем от С++, Первая же иерархия классов, действительно, позволила избавиться от многих неприятных моментов, таких как дублирование функциональности и инкапсулирование данных.
Потом всё быстро так стало не так радужно. Проект развивался, отношения между сущностями стали намного сложнее того, что можно спроецировать на С++ и, как грибы, стали расти откровенные извращения: использование инкапсуляции и виртуальных функций уже только для того чтобы соответствовать текущей системе классов. Появились какие-то промежуточные классы, ничего общего не имеющие с самой задачей(Технические так сказать
). Всё настолько усложнилось, что просто разобраться стало трудно. А конкретные исполнители, естественно, готовы были на что угодно, лишь бы их изменения были быстрей внесены в рабочую версию(они уже давно запутались в этой системе классов и она для них стала чем-то жутко сложным и непонятным)
Почему то начальство считало, что надо только придумать соответствующую систему классов - и тогда всё будет ОК. Мои замечания, что мол, кто Вам сказал, что такое в принципе возможно? воспринимались как откровенный саботаж и нежелание работать (Хуже нет начальника, прочитавшего введение к книжке по С++)
В итоге я написал проект на чистом С, простой, понятный и намного более эффективный(на 72%). Предоставил графики развития проекта, где показал, что с переходом на С++ мы только с каждым месяцем теряли на производительности проекта и большую часть времени проводили в отладке и извращениях, а не в полезном развитии.
Понятно, что я оказался только виновным, опять же, потому что не придумал ту самую мифическую систему классов, которая бы отражала нашу задачу
Эти поиски вынудили меня покинуть проект.
Есть задачи, которые просто идеально ложаться на ООП. Но их - абсолютное меньшинство. В примерах книжек именно эти случаи и приводятся. Правда, авторы не предупреждает, что этими примерами всё, собственно и ограничивается
Потом всё быстро так стало не так радужно. Проект развивался, отношения между сущностями стали намного сложнее того, что можно спроецировать на С++ и, как грибы, стали расти откровенные извращения: использование инкапсуляции и виртуальных функций уже только для того чтобы соответствовать текущей системе классов. Появились какие-то промежуточные классы, ничего общего не имеющие с самой задачей(Технические так сказать
). Всё настолько усложнилось, что просто разобраться стало трудно. А конкретные исполнители, естественно, готовы были на что угодно, лишь бы их изменения были быстрей внесены в рабочую версию(они уже давно запутались в этой системе классов и она для них стала чем-то жутко сложным и непонятным)Почему то начальство считало, что надо только придумать соответствующую систему классов - и тогда всё будет ОК. Мои замечания, что мол, кто Вам сказал, что такое в принципе возможно? воспринимались как откровенный саботаж и нежелание работать
(Хуже нет начальника, прочитавшего введение к книжке по С++)В итоге я написал проект на чистом С, простой, понятный и намного более эффективный(на 72%). Предоставил графики развития проекта, где показал, что с переходом на С++ мы только с каждым месяцем теряли на производительности проекта и большую часть времени проводили в отладке и извращениях, а не в полезном развитии.
Понятно, что я оказался только виновным, опять же, потому что не придумал ту самую мифическую систему классов, которая бы отражала нашу задачу
Эти поиски вынудили меня покинуть проект.
Есть задачи, которые просто идеально ложаться на ООП. Но их - абсолютное меньшинство. В примерах книжек именно эти случаи и приводятся. Правда, авторы не предупреждает, что этими примерами всё, собственно и ограничивается
Touareg
to kalon epieikes
Так и появляются утечки памяти)
С++ это круто, когда есть хороший архитектор, как известно ошибки проектирования обходятся дороже всего и в С++ это особенно заметно.
sami
Местный
Безусловно. Но объекты и наследования счастья не приносят, в отличие от повышения абстракции.
sami
Местный
Честно говоря, меня тоже смущает обилие звездочек в типах C/C++. Особенно какие-нибудь ботанические примеры из букварей без привязки к реальной жизни.
Сам уже давно не использую указатели и предпочитаю работать в языках, где их нет.
Это часть правды. Когда я ходил на горшок, так и было. Сейчас давно уже не грех разрабатывать компиляторы C++ на C++. Да и вообще на C++ очень много компиляторов написано.
Немного не так. C++ был как раз балансом между ООП парадигмой, представленной симулой и смолтоком, и производительностью "C". Причем C++ до сих пор удерживает лидерство по производительности среди ООП языков.
А появление производительных процессоров дала волю динамическим, функциональным языкам, виртуальным машинам и прочему, что требует дополнительные ресурсы на выполнение. Но все это произошло уже после того как на C++ выросло не одно поколение программистов.
sami
Местный
Спасибо за поучительный пример. Но мне кажется что роль С++ в нем преувеличена.
Соображения простые: "С" это есть подмножество С++. Потому оставаясь в рамках С++ но проводя сдержанность в выборе технических средств, можно было (теоретически) достичь того же результата. Т.е. заслуга в достигнутом именно Ваша, а не языка "C". Хотя он и играл роль сдерживающего фактора. Уверен в том что сейчас, используя свой опыт с "С", Вы смогли бы сделать не менее эффективный код на C++.
В реальных задачах вообще встает проблема положить их на что-нибудь. Естественно, что при ограничении выбора "на что класть" задача будет решаться еще сложнее. ООП в этом плане не лучше и не хуже любой другой парадигмы программирования. И т.к. серебрянной пули нет, то фора будет у тех, кто владеет множеством парадигм программирования и, более того, умеет их комбинировать. Соответственно инструментальные средства должны позволять это.Есть задачи, которые просто идеально ложаться на ООП. Но их - абсолютное меньшинство. В примерах книжек именно эти случаи и приводятся. Правда, авторы не предупреждает, что этими примерами всё, собственно и ограничивается
К сожалению, на практике приходится искать компромиссы между "красиво положить на подходящую парадигму", производительностью решения, производительностью написания кода, возможностями команды разработчиков, взглядами на проблему начальства, прытью продажников и т.п.
Естественно, примеры в книжках по ООП преследуют лишь одну цель - продемонстрировать преимущества ООП в конкретных ситуациях, да и нередко на конкретных языках. При этом история происхождения ОО костыля зачастую остается за кадром повествования. Так например часть ОО паттернов в GoF можно охарактеризовать фразой "моделирование отсутствующих в языке функций высших порядков с помощью подручных средств".