Стадион с огромным трафиком
Помимо магазинов и архитектурных памятников старины
Не увидел "архитектурных памятников старины" на картинках. Такой стадион не возможен — большинство зрителей на этой этажерке не будут видеть поле. Поэтому огромный трафик такому убогому сооружению не нужен.
Торговый комплекс — довольно сложное помещение
Да, постарались усложнить. Само помещение над парковкой, а входы/выходы по бокам с вертикальным подъемом на лифте? — Радостно на такое расстояние тележку с покупками катить! Стоить помещение будет дорого. Мировая практика — использовать подземные этажи для магазинов (там аренда дешевле), и использовать эскалаторы.
Картинку "Бесшовный офис" не понял и оценить не могу. Смотрится ИМХО бредом. Такое возможно построить? Похожа на детскую каляку.
Университет на этом фоне как-то выглядит. Хотя ИМХО входная дверь узковата, а витрины совсем не нужны. Посморите для интереса сколько дверей открывают в главном здании МГУ к началу занятий, а там входы с 4х сторон.
Очень много хороших свободных картинок в инете, как с Wi-Fi 6 Вы их не нашли?
Про проблемы нынешнего дизайна написал.
Уже писал раньше. Самое главное, что никак не доходит: даже очень хорошая реклама может играть обратную роль, когда надоедает.
ИМХО сейчас реклама часто имеет негативный эффект: при прочих равных, выбирая продукт в магазине, не куплю тот, реклама которого намозолила глаза — благодаря рекламе он мне уже надоел и стал неприятен.
Многие технологии стареют очень быстро. ИМХО реклама в нынешней форме устарела.
Так подумать и для GUI ООП не нужно: всего 4 "циферки" для каждого из десятков окошков — координаты верхнего левого и нижнего правого углов. А что окошки перекрываются, то это уже математика. "Зачем в подобных задачах ООП?" Перерисовывать окна по циклу, как было в ранних версиях MacOS — "просто же идеально для функций".
Согласен. Но расширять кругозор можно годами. А "джун" стареет. До 30 можно не беспокоиться, а когда 40+ уже дадут понять, что возраст перевешивает кругозор. (Я про знакомых).
Не увидел причины использовать объекты для этой задачи
А я там отметил случаи, когда методы будут различны (полиморфизм). Однако, все решенные задачи сводятся к ассемблеру без ООП. И GUI возможно сразу на ассемблере написать без ООП, но зачем такой мазохизм? Я писал код для GUI на Маке без ООП — остались сильные впечатления.
Можно это очень компактно и вполне эффективно сделать на Питоне
Не думаю, что с выборкой 90 "лимонов" графов по 10 вершин каждый Питон быстро справится. См. Вики:
Классический Python имеет общий со многими другими интерпретируемыми языками недостаток — сравнительно невысокую скорость выполнения программ
В начале 1990х ездил в Голландию на симпозиум. Выступил с докладом на английском, ответил на вопросы. Но прожив там неделю обнаружил пробелы в бытовой лексике: мне было не сложно говорить о производительности компа, но чтобы в отеле рубашку постирали пришлось в словарь заглянуть — не интересовался до этого словом "прачечная".
Вернувшись в Москву стал читать книги в оригинале, знакомые с детства в переводах. "Остров сокровищ" быстро прочел, а вот «The Adventures of Huckleberry Finn» — зубодробительно! Но автор честно предупреждает, что там 5 диалектов. BTW интересный вопрос: сейчас в США эту книгу печатают? Как решают вопрос с политкорректностью? Негр Джим заменяют на афроамериканец Джим?
Браво!
Всегда говорил и продолжаю говорить, что есть мат.моделирование, а есть лит.моделирование. У них разное устройство, но одно не хуже другого. М.б. поэтому одно дополняет другое. Нужен пруф? — Пожалуйста!: основоположник ИИ Ма́рвин Ли Ми́нский написал с известным литератором Гарри Гаррисоном роман "Выбор по Тьюрингу".
По работе решаю сложные н-т задачи в области мат.химии, при этом мне достаточно ООП Delphi-7, ну еще иногда CUDA-C. Раньше был нужен ассемблер — много их знаю, начиная с PDP-11, но к ООП это отношения не имеет. Интересуюсь экзотикой, нпр., ЯП Dee, но это факультативное любопытство ...
ИМХО тут работает Бритва Оккама: "Не следует множить сущее без необходимости". Факт, что м.б. примитивное ООП успешно работает во многих ЯП. Может и возможно усложнить, но зачем?
Но разговор про конкретный ЯП Java, и освоение его на уровне юниора. В некоторых ЯП есть хитрости, но если судить по tiobe, то у ML низкий рейтинг, а Smalltalk вне таблиц. Неужели Вы хотели сказать, что не зная ML и Smalltalk, невозможно понять инкапсуляцию, а, значит, ООП?
Разве инкапсуляция это не "сокрытие данных"? В Вики читаем:
Инкапсуля́ция (лат. in capsula; от capsula «коробочка») — размещение в оболочке, изоляция, закрытие чего-либо инородного с целью исключения влияния на окружающее. Например, поместить радиоактивные отходы в капсулу, закрыть кожухом механизм, убрать мешающее в ящик или шкаф.
Очень надеюсь, что очень долго при таком подходе. Сейчас многим таким, кто "Жизни" боится, удается устроиться и они начинают калечить хорошо работавшие сайты. Например, в крупном инет-магазине каждые 2 недели заказываю еду. Был удобный сайт, а теперь новый дизайн переселяет меня из Москвы в Тверь, что я не делай с профилем.
Написать "Жизнь" Конвея для него по-прежнему — сложно.
Уэзерелл свою великую книгу "Этюды для программистов" начинает главой под названием "Жизнь диктует свои законы" — ИМХО это название начинающим надо понимать буквально, а не только в применении к игре ;)
При всем уважении к автору (Страуструп) эта фраза вне контекста большого смысла не имеет. Для интереса погуглил:
Сказанное выше можно сформулировать более кратко и строго: объект — это инкапсулированная абстракция с четко определенным интерфейсом.… При этом нет необходимости иметь доступ к исходному коду родительского объекта. Наследование позволяет создавать иерархии объектов.
И чем это сложнее записи (record) примитивного Паскаля? Понятно ведь, что поля (x,y) записи point инкапсулированы в эту запись, и к ним нельзя обратится прямо, а только указав имя записи point.x. ИМХО сложное слово "инкапсулированы" интуитивно понятно: закопан внутри какой-то капсулы. Так локальные переменные функции закопаны в этой функции, и у нас нет к ним доступа вне функции.
И я уверен, что "юниорский уровень Java (без изучения алгоритмов)" никому вообще не всрался, ибо программирование != знание языка. Потому и не находят работу выпускники курсов. Язык они изучили, экосистему под него пощупали, а вот как задачи решать понятия не имеют даже в принципе.
Не увидел "архитектурных памятников старины" на картинках. Такой стадион не возможен — большинство зрителей на этой этажерке не будут видеть поле. Поэтому огромный трафик такому убогому сооружению не нужен.
Да, постарались усложнить. Само помещение над парковкой, а входы/выходы по бокам с вертикальным подъемом на лифте? — Радостно на такое расстояние тележку с покупками катить! Стоить помещение будет дорого. Мировая практика — использовать подземные этажи для магазинов (там аренда дешевле), и использовать эскалаторы.
Картинку "Бесшовный офис" не понял и оценить не могу. Смотрится ИМХО бредом. Такое возможно построить? Похожа на детскую каляку.
Университет на этом фоне как-то выглядит. Хотя ИМХО входная дверь узковата, а витрины совсем не нужны. Посморите для интереса сколько дверей открывают в главном здании МГУ к началу занятий, а там входы с 4х сторон.
Очень много хороших свободных картинок в инете, как с Wi-Fi 6 Вы их не нашли?
Про проблемы нынешнего дизайна написал.
Уже писал раньше. Самое главное, что никак не доходит: даже очень хорошая реклама может играть обратную роль, когда надоедает.
ИМХО сейчас реклама часто имеет негативный эффект: при прочих равных, выбирая продукт в магазине, не куплю тот, реклама которого намозолила глаза — благодаря рекламе он мне уже надоел и стал неприятен.
Многие технологии стареют очень быстро. ИМХО реклама в нынешней форме устарела.
Так подумать и для GUI ООП не нужно: всего 4 "циферки" для каждого из десятков окошков — координаты верхнего левого и нижнего правого углов. А что окошки перекрываются, то это уже математика. "Зачем в подобных задачах ООП?" Перерисовывать окна по циклу, как было в ранних версиях MacOS — "просто же идеально для функций".
Есть орграф, а есть не ор. Методы обхода будут разные.
У меня реальные задачи сложнее, чем в статье. Будет у Вас желание — можете порешать проблему тысячелетия про изоморфизм графов;)
Согласен. Но расширять кругозор можно годами. А "джун" стареет. До 30 можно не беспокоиться, а когда 40+ уже дадут понять, что возраст перевешивает кругозор. (Я про знакомых).
А я там отметил случаи, когда методы будут различны (полиморфизм). Однако, все решенные задачи сводятся к ассемблеру без ООП. И GUI возможно сразу на ассемблере написать без ООП, но зачем такой мазохизм? Я писал код для GUI на Маке без ООП — остались сильные впечатления.
Не думаю, что с выборкой 90 "лимонов" графов по 10 вершин каждый Питон быстро справится. См. Вики:
В начале 1990х ездил в Голландию на симпозиум. Выступил с докладом на английском, ответил на вопросы. Но прожив там неделю обнаружил пробелы в бытовой лексике: мне было не сложно говорить о производительности компа, но чтобы в отеле рубашку постирали пришлось в словарь заглянуть — не интересовался до этого словом "прачечная".
Вернувшись в Москву стал читать книги в оригинале, знакомые с детства в переводах. "Остров сокровищ" быстро прочел, а вот «The Adventures of Huckleberry Finn» — зубодробительно! Но автор честно предупреждает, что там 5 диалектов. BTW интересный вопрос: сейчас в США эту книгу печатают? Как решают вопрос с политкорректностью?
НегрДжим заменяют на афроамериканец Джим?Браво!
Всегда говорил и продолжаю говорить, что есть мат.моделирование, а есть лит.моделирование. У них разное устройство, но одно не хуже другого. М.б. поэтому одно дополняет другое. Нужен пруф? — Пожалуйста!: основоположник ИИ Ма́рвин Ли Ми́нский написал с известным литератором Гарри Гаррисоном роман "Выбор по Тьюрингу".
См. простейшие примеры.
И это уже не мало.
PPS Контрактное программирование — очень интересный подход. Может юниору нужно и его изучить? ;)
PS BTW у меня были работы на VBA, SQL, JS, Фортране.
По работе решаю сложные н-т задачи в области мат.химии, при этом мне достаточно ООП Delphi-7, ну еще иногда CUDA-C. Раньше был нужен ассемблер — много их знаю, начиная с PDP-11, но к ООП это отношения не имеет. Интересуюсь экзотикой, нпр., ЯП Dee, но это факультативное любопытство ...
ИМХО тут работает Бритва Оккама: "Не следует множить сущее без необходимости". Факт, что м.б. примитивное ООП успешно работает во многих ЯП. Может и возможно усложнить, но зачем?
Но разговор про конкретный ЯП Java, и освоение его на уровне юниора. В некоторых ЯП есть хитрости, но если судить по tiobe, то у ML низкий рейтинг, а Smalltalk вне таблиц. Неужели Вы хотели сказать, что не зная ML и Smalltalk, невозможно понять инкапсуляцию, а, значит, ООП?
Разве инкапсуляция это не "сокрытие данных"? В Вики читаем:
спасибо
PS Про похожие проблемы на Хабре написал "Печаль: Хабра больше не будет?"
Очень надеюсь, что очень долго при таком подходе. Сейчас многим таким, кто "Жизни" боится, удается устроиться и они начинают калечить хорошо работавшие сайты. Например, в крупном инет-магазине каждые 2 недели заказываю еду. Был удобный сайт, а теперь новый дизайн переселяет меня из Москвы в Тверь, что я не делай с профилем.
Уэзерелл свою великую книгу "Этюды для программистов" начинает главой под названием "Жизнь диктует свои законы" — ИМХО это название начинающим надо понимать буквально, а не только в применении к игре ;)
При всем уважении к автору (Страуструп) эта фраза вне контекста большого смысла не имеет. Для интереса погуглил:
И чем это сложнее записи (record) примитивного Паскаля? Понятно ведь, что поля (x,y) записи point инкапсулированы в эту запись, и к ним нельзя обратится прямо, а только указав имя записи point.x. ИМХО сложное слово "инкапсулированы" интуитивно понятно: закопан внутри какой-то капсулы. Так локальные переменные функции закопаны в этой функции, и у нас нет к ним доступа вне функции.
Полностью согласен. Я об этом и говорил.
Как эти правила разрешат проблемы, если в программе 10 000 строк и 100 переходов?