Форум программистов, компьютерный форум, киберфорум
ООП и паттерны
Войти
Регистрация
Восстановить пароль
Блоги Сообщество Поиск  
 
 
Рейтинг 4.53/90: Рейтинг темы: голосов - 90, средняя оценка - 4.53
 Аватар для tramp_1-3
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454

Недостатки ООП

16.05.2014, 16:35. Показов 22092. Ответов 318
Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам
Задали написать небольшую статью о недостатках этой замечательной парадигмы. В нашей группе прикладной информатики я один более-менее знаком с разработкой, поэтому на придирчивость аудитории можно не рассчитывать, и я решил спросить мнение опытных людей здесь. Я самоучка-теоретик, так и не написавший более-менее достой программы за свою жизнь, поэтому часть этой статьи навеяна из сети, а вот про усложнения - уже исключительной мой загон - не могу просто взять и написать программу. Пишу, думая, что это будет целый Фреймворк. Ну в общем предлагаю вашему вниманию эту коротенькую статью и рассчитываю на объективную критику. Всего полторы страницы - больше просто не знаю к чему придраться.
https://www.dropbox.com/s/m6u9... D0%9F.docx
дропбокс глючит и не дает нормальную ссылку. вот статья под спойлером.
Кликните здесь для просмотра всего текста
Недостатки ООП
Парадима ООП не нова. ООП приобрело популярность во второй половине 80-х вместе с такими языками, как Smalltalk, С++, Objective C (другое расширение C) и некоторыми другими. 25 лет назад никто не ожидал, что “новый” феномен ООП проживет столь долго и сегодня большинство современных языков поддерживают эту парадигму.
ООП стоит на трёх китах:
1.Первый — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП.
2.Второй — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации.
3.Третий, известный как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них.
Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают.
Преимущества этих языков всем известны: повторное использование кода, упрощение разработки больших программ, более логичная структура программы и многие другие. Разберём некоторые недостатки.
Недостатки есть абсолютно у всего – с этим нужно просто смириться. Важно адекватно их оценивать и стараться минимизировать их влияние. То же самое касается и объектно-ориентированной парадигмы программирования.
Есть несколько причин, почему узкие места ООП часто вылазят наружу. Я считаю, что это прежде всего непонимание самой сути объектно-ориентированной техники программирования - восприятие этой парадигмы как серебряной пули. Часто программисты стараются решать абсолютно все задачи, где даже не предвидится конкретных сущностей с их свойствами с помощью объектов, наследования и с помощью объектов. Это очень усложняет процесс. То есть вместо написания парочки функций в процедурной манере и передачи аргументов туда-обратно, программист часто пытается нагромоздить целую иерархию классов и после разгребает проблемы с видимостью классов, доступа к скрытым инкапсуляцией данным.
Таким образом, можно выделить один недостаток объектно-ориентированных языков программирования – избыточность их средств при решении большинства простых задач.
Нужно помнить, что применение ООП это прежде всего моделирование. Для построения хорошей, легко читаемой и сопровождаемой программы необходимо в самом начале разработки предусмотреть сценарии её использования и, что очень важно, изменения – заказчик легко в корне может поменять задачу. Это нетривиальный процесс, в котором часто задействуются даже отдельные языки моделирования. Не каждый способен выделить отдельные сущности и сделать их классами. Ещё меньше людей способны адекватно распределить функции, работающие с данными программы в методы и упаковать их в классы. Для этого нужно уметь мыслить объектно-ориентированными категориями. На всё это уходит драгоценное время. Оно обязательно окупится, если программист имеет дело с большим и сложным проектом, но вряд ли в других случаях, когда требуется просто решить задачу и перейти к другой.
Для меня вывод один, всем известный и общепринятый – не стоит воспринимать парадигмы и языки, их поддерживающие, как божество. Это всего лишь инструмент для решения определенного круга задач. Я думаю, что для объектно-ориентированных языков такие задачи начинаются, когда их решение укладывается более чем в тысячу строк и задачи, которые требуют масштабирования.
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
0
IT_Exp
Эксперт
34794 / 4073 / 2104
Регистрация: 17.06.2006
Сообщений: 32,602
Блог
16.05.2014, 16:35
Ответы с готовыми решениями:

Архитектура с толстым клиентом: какие есть недостатки?
Здравствуйте, коллеги! Сейчас разрабатываем простенькое веб-приложение для учета заказов производственной компании. Функционал несложный:...

ООП ради ООП
Доброго времени суток! Есть к примеру класс Cat который реализует интерфейс Movable, инкапсулирует цвет, и прочее. Имеет ли смысл...

Изучаю Python, сейчас учу основы ООП, где можно найти задачи по ООП
Скиньте пожалуйста источники с задачами(желательно на русском)

318
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 14:35
Студворк — интернет-сервис помощи студентам
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
У нас в России Программисты Java и JavaScript получают существенно больше, чем программисты на C++.
В росси не ведется разработка ни систем САПР ни систем АСУТП. Преимущественно сайтоклепательство. Отсюда и отсутствие з/п для тех кто на полюсах пишет. На западе абсолютно другая картина. В результате огромная нехватка спецов по плюсам со знанием разного матана а соответственно там где нехватка спецов там и высокая з/п. При этом все вакансии по С++ требуют знания определенных разделов математики в соответствии с направлением разработки. Без знания математики работы по С++ действительно нету.

Добавлено через 6 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
С "чистым" С++ уже "давно никто не работает"
Работают и еще как работают.
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Потому что это очень не дружелюбный и "вырвиглазный" язык
Это очень послушная в умелых руках дикая огнедышущая кобылица питающаяся человеченой. правда неопытного наездника не понимающего как комп функциклит и что он вообще хочет сделать затопчет и съест в два счета.

Добавлено через 46 секунд
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Именно поэтому большинство программистов не любят МАТАН, СОПРОМАТ, ТОЭ и т.п
Это не прораммисты а эникейщики. А программист это в первую очередь математик.

Добавлено через 1 минуту
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
И из хорошего инженера ВСЕГДА можно сделать хорошего программиста.
Для этого толковому инженеру нужно всего лишь еще 5 лет универа как минимум

Добавлено через 4 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Поэтому программировать АСУТП, знать ТАУ и прочее должны ИНЖЕНЕРЫ.
Вообще то это делают инженеры-программисты. Да кстати у нас к примеру в местном универе ТАУ читают двум специальностям - "прикладная математика и вычислительная техника" и "Автоматизация технологических процессов и производств".

Добавлено через 1 минуту
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
А вот из программиста ПОЧТИ НЕВОЗМОЖНО сделать хорошего инженера.
Потому как программист вместо начертательной геометрии во всю пользует аналитическую и вычислительную геометрию.

Добавлено через 4 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Программист - это в большинстве случаев НЕДОинженер.
Пытался на днях из двух инженеров с более чем 40-летним стажем работы ведущими технологами каждый вытащить простейшее правило из теормеха - сложение импульсов и моментов. В общем один ответ - ну ты и лезешь в дебри мы этого в институтах (в т.ч. в профильном заводском НИИ гиганта тяжелого машиностроения) не проходили. Вот вам и инженеры-механики...

Добавлено через 10 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
А вот из программиста ПОЧТИ НЕВОЗМОЖНО сделать хорошего инженера.
Хотя бы потому что для того чтобы написать софт для инженера программист должен разобрать предметную область на уровень знаний не хорошего инженера а ДОСКОНАЛЬНО. Ну а раз знания раскопал досконально то до уровня хорошего инженера их уже не понизит

Добавлено через 1 час 21 минуту
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
И кроме того, кол-во вакансий для первых больше чем для вторых.
Вопрос з/п это не вопрос количества вакансий а вопрос соотношения спроса и предложения. Там где ведется разработка математически нагруженного софта спрос на программистов С++ со знанием математики сильно превосходит предложение.
Ну а что явы и процего сайтоклепательства касается то основную масссу тянут выпускники школ и курсов. Отсюда и з/п по подавляющему большинству вакансий чуть выше квалифицированных рабочих.
Кстати и в странах СНГ там где есть разработка математически нагруженного софта (к примеру игровых движков) З/П для программистов С++ со знанием математики гораздо выше чем з/п по индустрии и вообще по стране. Другое дело что подходящих спецов найти очень трудно.
0
Заблокирован
03.09.2016, 15:17
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
В росси не ведется разработка ни систем САПР ни систем АСУТП.
Ну почему же.
Отдельные потуги есть.
Сейчас как грибы после дождя повылазили доморощенные отечественные SCADA и САПР-ы.
Вот Оси свои да. Не пишутся. И системы уровня MS Visual Studio - тоже. Увы.

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Работают и еще как работают.
Отдельные фанатики.
А большинство юсают разного рода надстройки, фреймворки и прочие "DSL-и" (тот же кутэ)

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Это не прораммисты а эникейщики.
Быдлокодеры

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
А программист это в первую очередь математик.
Программист (хороший программист) - это в первую очередь инженер. Ведь он занимается проектированием. А проектирование чего бы то ни было - это инженерная задача.

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Для этого толковому инженеру нужно всего лишь еще 5 лет универа как минимум
Пару месяцев. МАКСИМУМ. А вот на изучение предметной области нужно потратить 6 лет в институте. 3 года в аспирантуре и лет 25 отработать

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Потому как программист вместо начертательной геометрии во всю пользует аналитическую и вычислительную геометрию.
НЕ поэтому. Потому что программиста не учать ПРОЕКТИРОВАТЬ, не учат СИСТЕМНОМУ МЫШЛЕНИЮ. А без этого в программировании никуда

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
чтобы написать софт для инженера программист должен разобрать предметную область на уровень знаний не хорошего инженера а ДОСКОНАЛЬНО.
Где вы видели таких программистов?
Его даже закон Ома изучить не заставишь. Он начинает верещать "я ЧИСТО программист. Не буду я учить Вашу инженерную хрень"
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 15:20
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Пару месяцев. МАКСИМУМ
Язык хотя бы для начально изучить и базовые алгоритмы - месяца 4,. И 5 лет грызть математику шлифуя знания языка и умение создавать алгоритмы программируя оную.

Добавлено через 36 секунд
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Где вы видели таких программистов?
Программистов только таких и видел.

Добавлено через 46 секунд
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
А проектирование чего бы то ни было - это инженерная задача
Которая имеет под капотом очень даже четкие математические теории.

Добавлено через 15 секунд
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Быдлокодеры
Согласен
0
Заблокирован
03.09.2016, 15:26
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Пытался на днях из двух инженеров с более чем 40-летним стажем работы ведущими технологами каждый вытащить простейшее правило из теормеха - сложение импульсов и моментов. В общем один ответ - ну ты и лезешь в дебри мы этого в институтах (в т.ч. в профильном заводском НИИ гиганта тяжелого машиностроения) не проходили. Вот вам и инженеры-механики...
Это не инженеры.
Это младшие техники

Добавлено через 3 минуты
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Которая имеет под капотом очень даже четкие математические теории.
Большинство решаемых инженером задач НЕ ПОДДАЮТСЯ ФОРМАЛИЗАЦИИ
Работают только инженерная интуиция и опыт
Сложная навароченная математика используется в работе инженера крайне редко. В каких-то специализорованных узкозаточенных проектах. Типа проектирования Боинга

За 36 лет работы инженером разработчиком мне всего пару раз потребовались знания по математике, полученные в ВУЗ-е.
В большинстве случаев за глаза хватало школьного курса математики.
А вот системное мышление крайне требовалось.

А чтобы сайтики делать математика вообще не нужна
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 15:46
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Отдельные фанатики.
Фреймверки тоже люди пишут. И движки игровые к примеру. И не только игровые но и инженерные. К примеру тот же SolidWorks. Вся инженерная часть на голом MSVC с нуля (т.е. свой фреймверк и на его основе наращивание функционала). Интерфейс похоже тоже свой фреймверк на голом С++ и WinAPIа не MFC. И так везде в серьезном инженерном и т.п. софте. А все фреймверки массового пользования обычно рассчитаны либо на расширение так что для многих задач проще с нуля сделать (к примеру MFC) либо под бизнес-логику либо рассчитаны на бизнес-логику информационных систем крупных корпораций - т.е. ту нишу которой спецам С++ заниматься становится вообще некогда.

Добавлено через 3 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Большинство решаемых инженером задач НЕ ПОДДАЮТСЯ ФОРМАЛИЗАЦИИ
Угу... "Какой на ... брак не выкидывать такую же груду металла на .. заваривать к ... матери и придумывать что немчуре (тех приемке заказчика) объяснять. (с) Зам.начальника цеха по поводу открывшейся в заготовке барабана лебедки портального крана полуметровой раковине.

Добавлено через 5 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Большинство решаемых инженером задач НЕ ПОДДАЮТСЯ ФОРМАЛИЗАЦИИ
А задача софта не столько находить решение/компановку и т.п. (хотя и в этом плане кое что можно) сколько найденное решение обсчитать промоделировать и т.д. чтобы еще на этапе проектирования избежать ошибок. (т.е. фактически задача САПР заменить отдел-другой расчетчиков ), автоматически подготовить документацию (т.е заменить отдел-другой чертежников), создать маршруты обработки и сгенерировать управляющие программы для обрабатывающих станков (хотя на самом деле это по большому счету не программы а чертежи в определенном понятном станку формате).

Добавлено через 4 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Это не инженеры.
Это ведущие инженеры-технологи с 40-летним стажем (а кое кто и начальником тех бюро одно время работал). Ударники производства и т.д. Причем реально лучшие в редукторном цехе. Оно им просто сто лет никогда в реальной работе нужно не было и в такие дебри как силы приложенные к телу в 3D они похоже действительно ни в институте ни в реальной работе не сталкивались. Так же как к примеру и с пересчетом момента инерции относительно оси не параллельной главным осям тела.

Добавлено через 3 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
НЕ поэтому. Потому что программиста не учать ПРОЕКТИРОВАТЬ, не учат СИСТЕМНОМУ МЫШЛЕНИЮ. А без этого в программировании никуда
ЩАЗ. Это основное чему программиста учат. Системный анализ. Разработка любого софта начинается с анализа предметной области и постановки задачи. И только потом уже програмная реализация.

Добавлено через 2 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
За 36 лет работы инженером разработчиком мне всего пару раз потребовались знания по математике, полученные в ВУЗ-е.
Млин... а мне вузовских каждый день не хватает... приходится постоянно справочники капать да и в тех хрен найдешь... к примерру пересечение луча с тором так и не нашел. так же как и к примеру пересечение тора с квадрикой. приходится самому выводить...
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,113
Записей в блоге: 2
03.09.2016, 15:48
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Не пишутся. И системы уровня MS Visual Studio - тоже. Увы.
Не "увы", а "слава богу" что хватает ума не писать такой кал как MSVC

Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Пару месяцев. МАКСИМУМ. А вот на изучение предметной области..
Видимо этот "большой" максимум отражает Ваш личный двухмесячный опыт

Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Его даже закон Ома изучить не заставишь. Он начинает верещать "я ЧИСТО программист. Не буду я учить Вашу инженерную хрень"
К сожалению, тут Вы совершенно правы. Пренебрежение предметной частью - беда многих (а может и большинства). Вместо нее поедается огромное кол-во "плюшек" (новых технологий, классов. фреймворков и.т.п). Задачки типа "найти расстояние от точки до прямой" обычно непосильны, более того, существует весьма распространенное мнение, что, дескать, программисту этого и уметь не надо - нашел готовое решение, подключил - вуаля
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 16:22
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
В большинстве случаев за глаза хватало школьного курса математики.
А вы проекты свои просчитывали ну к примеру на то чтобы при разрушении агрегата все обломки остались внутри корпуса? Ну или работу под нагрузкой с учетом деформаций? А современные САПРы это обсчитывают.

Добавлено через 4 минуты
Цитата Сообщение от Igor3D Посмотреть сообщение
Вместо нее поедается огромное кол-во "плюшек" (новых технологий, классов. фреймворков и.т.п).
У нас другой подход был у препадов. Дали 2 языка за первый курс. Дальше задачи с упором на предметные области и естественно параллельно математика чтобы в этих предметных областях разбираться мог. А какими инструментами реализовывать - сам выбирай и за плюшками и т.п. новых инструментов/фреймверков сам следи, ты же спец. Время кстати было как раз был качественный скачок всех этих плюшек.

Добавлено через 2 минуты
Цитата Сообщение от Igor3D Посмотреть сообщение
Задачки типа "найти расстояние от точки до прямой" обычно непосильны, более того, существует весьма распространенное мнение, что, дескать, программисту этого и уметь не надо - нашел готовое решение, подключил - вуаля
Реально эникейщики. Те из нашей группы кто так же думал теперь кто кассиром работает у интернет провайдеров кто в саппорте.

Добавлено через 22 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
В каких-то специализорованных узкозаточенных проектах. Типа проектирования Боинга
А в проектировании банального редуктора банального ВАЗ разве прочностные расчеты не нужны? Или при проектировании кузова не нужно жесткость силовых конструкций рассчитывать так чтобы в случае аварии они поглотили большую часть энергии удара а не передали ее в салон?
0
Заблокирован
03.09.2016, 16:32
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Оно им просто сто лет никогда в реальной работе нужно не было
О чем я Вам и говорил: в подавляющем числе случаев в реальной практике инженера за глаза хватает школьной математики. 6-го класса. Думаю что у программистов аналогичная ситуация.

Добавлено через 1 минуту
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Млин... а мне вузовских каждый день не хватает... приходится постоянно справочники капать да и в тех хрен найдешь... к примерру пересечение луча с тором так и не нашел. так же как и к примеру пересечение тора с квадрикой. приходится самому выводить...
У Вас просто очень специфическая область. Таких в России крайне мало.
Но Вы не думайте, что раз Вы используете в работе высшую математику, а я нет, то значит у меня работа простая а у Вас сложная.

Математика может вообще не использоваться.
А при этом проблема будет крайне сложной. Голову сломаешь
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 16:36

Не по теме:

Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Типа проектирования Боинга
Шутка юмора. Летит Боинг в непогоду. Ну болтанка. Один пассажир бледнеет чуть ли не в обморок падает и т.д.
К нему стюардесса подходит:
- Что вас так беспокоит?
Пассажир:
- Крыло гнется!!!!
Стюра:
- Ну это же самолет Боинг. Вот посмотрите - все вокруг спокойны они знают что самолет проектировали настоящие профессионалы и он на все это рассчитан...
Пассажир:
- А я начальник отдела прочностных расчетов корпорации Боинг и знаю КАК он рассчитан.



Добавлено через 1 минуту
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
в подавляющем числе случаев в реальной практике инженера за глаза хватает школьной математики. 6-го класса.
В нее арифметика указателей не входит.

Добавлено через 2 минуты
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
в подавляющем числе случаев в реальной практике инженера за глаза хватает школьной математики
НЕ вот к примеру длину общей нормали косозубого колеса посчитать или еще что в этом духе это им запросто. Тоже далеко не школьная математика. А такого просто в те времена когда они учились не считали. Компов не было. Посему механизмы проектировали так чтобы все моменты в 2D складывались либо как понимаю считали приблизительно в 2D и делали какой то запас прочности и т.п. на 3D
0
Заблокирован
03.09.2016, 16:39
Цитата Сообщение от Igor3D Посмотреть сообщение
Задачки типа "найти расстояние от точки до прямой" обычно непосильны, более того, существует весьма распространенное мнение, что, дескать, программисту этого и уметь не надо - нашел готовое решение, подключил - вуаля
Вот вот. Сплошь и рядом такое.
Задачку можно в уме решить за 2 минуты. Если чуть-чуть поразмышлять.
А программист ищет в гугле специальный фреймворк, для решения этой задачи.
А головой подумать никак.

Добавлено через 1 минуту
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
А вы проекты свои просчитывали ну к примеру на то чтобы при разрушении агрегата все обломки остались внутри корпуса?
Зачем?
Мне это НИКОГДА не было нужно.
И потом. Математика не должна заменять здравый смысл.

Добавлено через 1 минуту
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
А в проектировании банального редуктора банального ВАЗ разве прочностные расчеты не нужны? Или при проектировании кузова не нужно жесткость силовых конструкций рассчитывать так чтобы в случае аварии они поглотили большую часть энергии удара а не передали ее в салон?
Инженеры-прочностники-расчетчики - это очень узкая мизерная прослойка инженеров.
Их меньше 0.1% от общего числа инженеров
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 16:51
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
А программист ищет в гугле специальный фреймворк, для решения этой задачи.
Ну фреймверк не фреймверк а библиотечка векторной алгебры заточенная под применение в вычислительной геометрии была бы кстати. Операторы над векторами. Тогда вообще одной операцией находится. Записывать гораздо удобнее просто чем каждый раз с x y z маяться. Хотя если там тлько вектора это строк 50-100 от силы библиотечки со всеми нужными операторами.

Добавлено через 5 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
А программист ищет в гугле специальный фреймворк, для решения этой задачи.
А головой подумать никак.
Программист как раз головой и думает. Только на тему сколько миллионов раз в секунду ему эту задачу решать нужно. А фреймверк по всей видимости обеспечивает доступ к решателю. К примеру к GPU. Туда просто так свои расчеты не закинешь только через специальные системные библиотеки/фреймверки

Добавлено через 5 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Инженеры-прочностники-расчетчики - это очень узкая мизерная прослойка инженеров.Их меньше 0.1% от общего числа инженеров
Вот наверное поэтому то что коробка передач танка Т-34 выдерживала аж 350-400 км в СССР считали офигенным достижением.
А у фашистов то что коробка передач САУ "ЯгдПантера" выдерживала 500 км считали катастрофическим про..ом проектировщиков и рассматривали по этому поводу вопрос прекращения ее производства
0
Заблокирован
03.09.2016, 16:51
Fulcrum_013
Вы все заладили "математика, математика!"
Да полно задач в которых знание тензорной алгебры и дифуров с матаном никак не поможет.

Вот как Вы с помощью математики решите такую задачу:
Посоветуйте софт для облегчения анализа и сокращения объема чужого кода
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 16:53
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
И потом. Математика не должна заменять здравый смысл.
А при таких расчетах она его не заменяет а дополняет.
0
Заблокирован
03.09.2016, 16:54
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Вот наверное поэтому то что коробка передач танка Т-34 выдерживала аж 350-400 км в СССР считали офигенным достижением.
А у фашистов то что коробка передач САУ "ЯгдПантера" выдерживала 500 км считали катастрофическим про..ом проектировщиков и рассматривали по этому поводу вопрос прекращения ее производства
Вот опять же Вы своим пример доказали, что мою убежденность, что "ЗДРАВЫЙ СМЫСЛ ВАЖНЕЙ МАТЕМАТИКИ".

Немецкий "ягуар" был очень хороший танк. Но цикл его производства составлял ПОЛГОДА.
А русский танк был значительно хуже. Но цикл его производства 2 недели.

И вот спрашивается: нафига делать танк полгода если его подобьют в первом же, от силы во втором бою?

ЗДРАВЫЙ СМЫСЛ РУЛИД
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 16:56
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Вот как Вы с помощью математики решите такую задачу:
Как конкретно нужно разбираться но семиотика и теория конечных автоматов в этой задаче будут рулить во всю.

Добавлено через 1 минуту
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
нафига делать танк полгода если его подобьют в первом же, от силы во втором бою?
Подобъют и уничтожат это две большие разницы. Безвозвратные потери немцев в бою под Прохоровкой составили 4 танка.
0
Заблокирован
03.09.2016, 17:00
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Безвозвратные потери немцев в бою под Прохоровкой составили 4 танка.
Войну в результате выиграли мы.
Потому что благодаря ЗДРАВОМУ СМЫСЛУ мы поняли, что не нужны нам самые лучшие самолеты и танки. Выигрывает войну тот, не у кого танки/самолеты лучше, а тот, кто сможет их выпускать больше. В результате мы по производству танков и самолетов в 10 раз обошли немцев.
Потому и войну выиграли.
Пока они старались усовершенствовать свои самолеты/танки мы тупо гнали вал.
И результаты войны доказали, что мы были правы.
Здравый смысл рулит

Добавлено через 28 секунд
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Как конкретно нужно разбираться но семиотика и теория конечных автоматов в этой задаче будут рулить во всю.
Это все просто слова.
И ваша наивная веря во всесилие математики
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 17:11
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Войну в результате выиграли мы.
Реально если верить постановке вопроса Сталиным что война это столкновение экономик то ее выиграли по большому счету Англичане с Американцами

Добавлено через 7 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
производству танков и самолетов в 10 раз обошли немцев
По одной простой причине - им и на те что у них были горючки не хватало. А вот в этом плане как раз союзники постарались. И еще в одном плане постарались - вынудили не менее 10 тысяч крупнокалиберных орудий постоянно смотреть в небо в западном направлении. Для сравненияя под Сталинградом у немцев было до 3000 орудий и минометов
0
Заблокирован
03.09.2016, 18:14
Fulcrum_013, Как видите. Везде рулид здравый смысл, а не математика.
И ВЫСШАЯ математика, на самом-то деле, нужна крайне редко для крайне узкого числа узкозаточенных специалистов

А 99,8% инженеров и программистов в их повседневной работе за глаза хватит школьной математики уровня 6-го класса

Заставлять ВСЕХ ПОГОЛОВНО инженеров и программистов 4 года(!!!) учить ВСЮ высшую математику в ВУЗе - ИМХО глупо да и не нужно

А вот здравому смыслу, инженерному подходу и системному мышлению надо учить ВСЕХ ПОГОЛОВНО технических специалистов. Даже применяя для этого насилие

И шпицрутены

Это гораздо важней чем обучение манипулированию значочками и символами в вышей математике
0
 Аватар для Fulcrum_013
2083 / 1575 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
03.09.2016, 18:36
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
инженеров
всю глупо
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
программистов 4 года(!!!) учить ВСЮ высшую математику в ВУЗе
не 4 а 5 просто необходимо. потому как если 5-7 человек из группы освоят это уже гуд и то им хватать не будет. Остальные обычно один хрен ничему не научатся. При этом "термина програмvное" обеспечение не существует. Существует термин "Математическое обеспечение ЭВМ"
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
инженерному подходу и системному мышлению надо учить ВСЕХ ПОГОЛОВНО технических специалистов
Вот те которые 5 лет эту математику грызут и ее же программят как раз системный подход и осваивают. Потому как эта математика нужна для анализа предметной области которую учатся анализировать. И то с математикой не всегда успевают. Как то на втором курсе надо было посчитать количество треугольников необходимых для модели сферы. Помозговал с часик сделал. На третьем курсе узнал из лекции по "Теории поля" что эта штука которую тогда придумал называется поверхностный интеграл.

Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Даже применяя для этого насилие
Добавлено через 20 секунд
И шпицрутены
А те кто не желает - их даже советская власть заставить учится не смогла.

Добавлено через 8 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Это гораздо важней чем обучение манипулированию значочками и символами в вышей математике
Эти значечки и символы в результате роботами манипулируют и т.п. Да кстати учат программеры обычно такую математику о которой препады с кафедры вышки обычно дай бог чтобы названия разделов слышали.

Добавлено через 7 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Как видите. Везде рулид здравый смысл, а не математика.
Ну да. Амеры с Англичанам четко посчитали расклады. Здравый смысл он всегда на четком расчете держится. К примеру амеры четко просчитали что если дать гитлеру бензы а японии дать напасть на СССР потом самим буде очень невесело. Посему во первых вошли в Иран и скинули там прогитлеровски настроеного шаха. Во вторых Штаты подтолкнули Японию к нападению на них а не на СССР. В третьих четко расчитали силы и правильное расположение аэродромов в Битве над Каналом. Потом просто устраивали 2 года операцию "Цирк" над каналом 2-3 эскадрильями не давая перебросить на восточный фронт зенитную артиллерию. Ну и всю войну бомбили нефтепромыслы Плоешти.
Остальное все было делом обычного экономического превосходства США над Германией а особенно в условиях резкого дефицита нефти в Германии.Вот и здравый смысл на точном четком расчете.
0
Заблокирован
03.09.2016, 20:45
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
При этом "термина програмvное" обеспечение не существует. Существует термин "Математическое обеспечение ЭВМ"
Где?
В старых совковых учебниках?

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
К примеру амеры четко просчитали что если дать гитлеру бензы а японии дать напасть на СССР потом самим буде очень невесело.
Используя математические формулы и дифуры "просчитали"?
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
BasicMan
Эксперт
29316 / 5623 / 2384
Регистрация: 17.02.2009
Сообщений: 30,364
Блог
03.09.2016, 20:45

Недостатки React
Здравствуйте. Расскажите пожалуйста о недостатках, архитектурный просчетах, неудобствах и т.д. с которыми вы сталкивались при написании...

Укажите на недостатки
Нужна ваша помощь. Написал я программу, которая вычисляет число Pi (в дальнейшем хочу добавить другие числа, и методы вычисления), это моя...

Недостатки AnyLogic
Сразу отмечу - я далёк от программирования и не имеют опыта работы в AnyLogic. Поэтому высказанное ниже носит субъективный характер и...

Какие недостатки
Люди, что можите сказать о http://www.rucar.ru? Заранее спасибо! :)

недостатки системы
Пожалуйста, скажите, кому что не нравится в windows 7 с точки зрения безопасности.


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
160
Ответ Создать тему
Новые блоги и статьи
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным?
anaschu 12.07.2026
Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .
сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию.
anaschu 12.07.2026
Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .
Сукцессия 26. Мат модель создана.
anaschu 12.07.2026
Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .
Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста".
Hrethgir 12.07.2026
Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок
anaschu 12.07.2026
# От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .
сукцессия 24. Промежуточное общее описание модели
anaschu 12.07.2026
Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .
сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры.
anaschu 12.07.2026
Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .
сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато
anaschu 11.07.2026
Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2026, CyberForum.ru