Скорее забавно, что MS не смог купить Java и ему пришлось сначала пилить J++, а потом J# и C#.
А Oracle смог купить, но когда уже нет возможности извлечь из этого выгоду.
Инертность мышления во всей красе… Сначала в MS не верили в то, что Интернет станет популярным, а потом в то, что смартфоны станут популярными. И там и там у них были свои решения, но такие… для галочки. Какого-нибудь из первых конкурентов обойти и забить лет на 5. А за это время другие конкуренты их самих обходили.
Ну да, 15-20 лет назад вопросы лицензий в России вообще мало кого интересовали.
Плюс в ВУЗы они поставляли бесплатные лицензии, насколько я помню. А традиция обучения программированию на базе Паскаля была очень сильна.
Именно это под словом "пивот" и подразумевают, проект меняется иногда даже больше, чем на половину, и по сути да — это уже новый проект, но часть кодовой базы можно переиспользовать.
Чем приложение меньше, тем меньше смысла грузить немаленький jQuery
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
Насчёт красоты wxWidgets можно ещё добавить, что он подстраивается под нативный look-n-feel, поэтому скриншот одной и той же формы будет выглядеть по-разному в разных OS и DE. Например, на MacOS X такой вид:
Так что для кросс-платформенного GUI wxWidgets — практически идеальный вариант.
Ответ, вообще-то, очевиден — только не таков, каким он вам кажется.
Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.
Авторы Inkscape, вообще-то, начинали с исходников Sodipodi, созданном на языке C без использования ООП.
Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD
Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)
Разумеется когда вы добавляете ООП в уже существующий код — ваши руки оказываются «связанными».
Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.
А речь шла не про определение, а про утверждение, что ООП придумали не для простых задач.
Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.
И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.
Конечно не каждый студент будет делать в своей работе векторный графический редактор… Ну так то же самое можно про что угодно сказать.
Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).
P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.
Рекурсивность появится если паттерн будет состоять из самого себя, а не просто из набора других паттернов.
Если бы было так:
var person = new Person
{
Name = new FullName
{
First = "Vasya",
Last = "Pupkin",
X = "secret",
},
Age = 42,
};
if (person is { X: var x})
{
Console.WriteLine(x);
}
то можно было бы сказать, что есть рекурсивный паттерн, который соответственно запускает рекурсивный поиск совпадения на любую глубину вложенности.
Если изучаете конкретный граф, то его ввести в комп сначала надо.
Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..
И, опять, кто Вам сказал, что ООП придумали не для простых задач?
Это просто факт. Читайте первоисточники.
Что значит «просто другая»? Там что: другие компы, другие ОС, другие ЯП?
То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).
Да, и эти люди обычно решают наиболее сложные задачи.
Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.
В пром. разработках очень много тривиальных задач.
Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
Это неважно. Важно, что нетривиальных задач тоже много.
Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
Примеры разбора их неадекватности: 1, 2
ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
Но название фичи ведь должно кратко описывать её суть, а не просто из случайных слов состоять? А тут в чём рекурсивность? Тут скорее "Nested deconstruction"
Зависит от степени вашего формализма )))
Можно понимать первый пункт так:
Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.
При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.
В РФ подоходный налог на выигрыши — 35%, хотя может для казино и есть какие-то исключения. Но скорее исключения только для государственных лотерей.
Почему задаром то? При желании, MS и оплатит.
Скорее забавно, что MS не смог купить Java и ему пришлось сначала пилить J++, а потом J# и C#.
А Oracle смог купить, но когда уже нет возможности извлечь из этого выгоду.
Инертность мышления во всей красе… Сначала в MS не верили в то, что Интернет станет популярным, а потом в то, что смартфоны станут популярными. И там и там у них были свои решения, но такие… для галочки. Какого-нибудь из первых конкурентов обойти и забить лет на 5. А за это время другие конкуренты их самих обходили.
Ну да, 15-20 лет назад вопросы лицензий в России вообще мало кого интересовали.
Плюс в ВУЗы они поставляли бесплатные лицензии, насколько я помню. А традиция обучения программированию на базе Паскаля была очень сильна.
Учительница, видимо, подустала играть в компьютер, поскольку итоговый алгоритм всё ещё никуда не годится )))
Что-то непонятно… А где взять шарики малинового мороженого? Где фабричный метод их создания?
Зачерпни соус чем?
Прям вот так вот вверх ногами и вернуть упаковку на место?
Логично, в фотошопе то этих названий нет. А откуда берёт цвета верстальщик? Правильно, из того самого макета в фотошопе.
Именно это под словом "пивот" и подразумевают, проект меняется иногда даже больше, чем на половину, и по сути да — это уже новый проект, но часть кодовой базы можно переиспользовать.
Насколько я понимаю, они со временем выпиливают слой совместимости с совсем уж древними браузерами, и как следствие размер библиотеки уменьшается со временем. Ради интереса посмотрел, текущая версия (3.4.1) занимает 86 kb и это ещё без gzip. По текущим реалиям будет точнее называть его "пренебрежимо маленький jQuery".
Вынос в константы однозначно нужен. А вот вынос в конфиг может оказаться и оверинженерингом. Про YAGNI тоже не нужно забывать.
Насчёт красоты wxWidgets можно ещё добавить, что он подстраивается под нативный look-n-feel, поэтому скриншот одной и той же формы будет выглядеть по-разному в разных OS и DE. Например, на MacOS X такой вид:
Так что для кросс-платформенного GUI wxWidgets — практически идеальный вариант.
Если вы намекаете, что ответ — "исторически сложилось", то это неправильный ответ.
Ох, как же вы живёте то теперь со знанием, что векторный редактор можно и без ООП написать xD
Кстати, в C вполне возможно использовать ООП (не забывайте, что это парадигма, и что наличие классов — не является её требованием)
Что значит "разумеется"? Inkscape уж 15+ лет существует… пару раз что угодно переписать можно было, если бы была насущная необходимость.
Да и вообще когда есть понимание, как надо переделать и зачем, руки ничто не связывает.
Если про это не написали в русской Википедии на странице про ООП, то для вас это неочевидно?
Я бы даже сказал, что не слишком громким обобщением, будет сказать, что в программировании уже лет 70 как ничего не придумывают для простых задач. Основной драйвер развития парадигм и инструментария — борьба со сложностью.
И именно на этой борьбе построили удачные маркетинговые компании, которые реализовали небольшое подмножество идей ООП, типа того же C++. Да с него плевались те, кто придумал ООП, писали "что за хрень?", но маркетинг сделал своё дело. Но это 35 лет назад можно было на что угодно навесить ярлык ООП, лишь бы продать. Сейчас любой желающий может ознакомиться с оригинальным описанием парадигмы, осознать масштабы концептуальных искажений в мейнстрим языках и сделать выводы. И практически применимые выводы, потому что ООП — это не технология, а парадигма — совокупность идей и понятий, определяющих стиль написания программ. Как только поймёте парадигму, сможете начать её применять в любом языке.
Как сказать… Есть классы задач, которые решаются постоянно, ежедневно в тысячах компаний по всему свету, просто потому что универсального решения нет или пока не нашли, но есть универсальные принципы и подходы к их решению. И именно их было бы гораздо полезнее рассматривать в учебных целях. Нечто подобное рассматривают в книгах про паттерны проектирования.
Вот только это сложный и путанный путь: сначала объяснить ООП так, чтобы никто не понял зачем оно, а когда задолбается, начал паттерны изучать или переизобретать.
Обратите внимание, почти все паттерны выделяют объекты по поведению (поведение + данные, необходимые для его реализации), а почти все учебники и статьи для начинающих продолжают нести дичь про объекты реального мира и про то, что объект — это модель, это данные и всевозможные действия над этими данными (= фундаментальная ошибка понимания ООП).
P.S. Вы всерьёз думаете, что формат комментариев подходит для обсуждения создания векторного редактора с нуля? Мало того, что это практически бессмысленная задача (у вас бюджета не хватит подвинуть конкурентов), так она ещё и огромна.
Но раз уж вам захотелось дзена, то почитайте исходники того же Inkscape и ответьте на вопросы: Почему класс Circle не наследует от класса Shape? И не содержит метода draw? Авторы Inkscape не дураки, чтобы делать так, как описано в "учебниках" по ООП.
Вот с этим не поспоришь :)
Жаль только в заголовке оно упоминается )))
Рекурсивность появится если паттерн будет состоять из самого себя, а не просто из набора других паттернов.
Если бы было так:
то можно было бы сказать, что есть рекурсивный паттерн, который соответственно запускает рекурсивный поиск совпадения на любую глубину вложенности.
Так ввести (в виде данных), или вывести на монитор в виде картинки? Вы уж определитесь там..
Это просто факт. Читайте первоисточники.
То и значит. Разные условия, разные цели, разные типы задач, разные процессы разработки. Да и языки другие, для научной разработки лучше всего подходят Haskell, Idris, Matlab, Fortran, etc. Julia вон недавно завезли, не пробовали ещё?
А ООП вам там в подавляющем большинстве задач нафиг не сдалось, если честно. Научная разработка — вотчина ФП (чистая математика, самый сок) и ПП (там где скорость критична, а алгоритмов с неизменяемыми данными не хватает).
Это смотря по каким критериям измерять сложность. Вы лишь сравниваете что зеленее? тёплое или мягкое?
Посади тех же людей, которые решают сложные научные задачи, писать промышленный проект средней руки, и они облажаются по полной. Так же как и в обратную сторону.
Можно подумать в научных мало… Все расчёты сводятся в конечном итоге к большому кол-ву тривиальных задач.
Это неважно. Важно, что нетривиальных задач тоже много.
Имхо, не стоит ничего объяснять на искусственных примерах. И да, это общий вопрос для любых концепций. Всегда можно найти достаточно простой пример, но при этом адекватный и практически применимый.
Проблема в примерах с фигурами и животными, в том, что они сами по себе являются примерами непонимания как и зачем применять ООП, примерами того, как делать не надо. При этом люди на них осваивают это самое ООП. А потом, когда они набираются опыта, пишут статьи типа "Чем быстрее вы забудете ООП, тем лучше для вас". А всё потому, что изначально учились на дрянных и совершенно неадекватных примерах.
Примеры разбора их неадекватности: 1, 2
ООП — полезная парадигма, но только если понимать зачем она была создана и для чего. А пока в книгах продолжают писать, что ООП моделирует объекты реального мира, мы так и будем иметь всё новые поколения программистов, не понимающих ООП.
Но название фичи ведь должно кратко описывать её суть, а не просто из случайных слов состоять? А тут в чём рекурсивность? Тут скорее "Nested deconstruction"
Зависит от степени вашего формализма )))
Можно понимать первый пункт так:
Программа состоит из объектов, нет никакого кода, исполняющегося вне объектов.
При этом что там внутри объектов происходит (п.3) и как они коммуницируют (п.2) — темы отдельные и формально не требуют ни наличия объектов внутри own memory объекта, ни использования объектов для передачи сообщений.