Обновить
15

Программист

Отправить сообщение

Очень хорошо структурированная статья. Плюсую.

Но автор ничего не сказал про "грязные" языки объектно-ориентированного программирования в статье. А именно, из-за "грязности", и пошло много такого странного понимания ООП, я считаю.

Насколько я знаю Internet Recovery стали добавлять в прошивку компьютеров Apple с середины 2011 года. У меня 2007 года iMac. По этому я в "пролёте")

Я с этой статьи начинал и у меня не получилось сделать загрузочную флешку.
А вы какой DMG-образ успешно смогли развернуть на флешку? Ссылку или название файла помните?

Количество фотографий Маска в этой статье похоже достигла максимума. Хмм... Вам точно Маск ничего не проплачивал?... И Тесла, которая припаркована недалеко от дома где Вы живёте, точно не Ваша?)

Есть такой университет УПП. Так там целая система разработана по работе над собой через прививание новых привычек. Называется Дистанция. Ей уже больше 10 лет. С ней не встречались?

Смело, смело. Подпиливать такой огромный проект - Вы наверное весьма не ординарный программист!)

Интересный синтаксис определения классов. Я если буду улучшать свой littlelisp.js возможно попробую перенять некоторые конструкции.

Правда, пересылка сообщений, на мой взгляд, усложнение. Можно и просто сделать поиск и вызов метода объекта.

Задам свой любимый вопрос: а с отладкой как обстоят дела?
80% времени и нервов уходит именно на этот процесс. Что Вы сделали, чтоб программисту на Вашем языке было удобно отлаживать свой код?

Если у вас такой богатый функционал, то почему нет статьи ?

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

Я не про Smalltalk говорил.

Про посылку сообщения я говорил относительно статьи, где указано, что это один из основных принципов ООП. Мне кажется, что объектам не обязательно слать друг другу сообщения. Можно и по другому взаимодействовать. И при этом объекты останутся объектами и программирование будет объектно-ориентированным и дальше.

В моём понимании объекты на первом месте. А то, как они взаимодействую, это уже каждый выбирает сам.

Ясно. Ясно. Я понял Ваш подход. Это хорошо, что Вы придумали свой подход. Больше библиотек - больше шансов найти что-то по душе)

В моём случае вместо 0 можно и $i поставить. Это же строка в двойных кавычках. Можно ещё * поставить, тогда обойдены будут все элементы и результат вернётся списком. Можно и фильтр использовать в [] как в xpath. Есть и функция if() и другие. Но в любом случае Ваш подход тоже хорош: он будет работать быстрее чем у меня. У меня всё таки парсинг выражения происходит перед его исполнением, а это лишние вычисления.

Я за годы программирования на Smalltalk привык, что ООП - это когда объекты реального мира отображаются на объекты в коде. Этот подход прост и достаточно хорошо работает по моему опыту.

При этом не обязательно посылка сообщения должна быть. Когда объект в реальном мире взаимодействует с другим (например прикасается или давит на другой), он не посылает сообщений. Технически, программно можно вызвать метод или занести значение в публично доступное поле объекта.

Есть ещё такой вопрос: а действия могут быть объектами? А то я часто встречаю когда их упаковывают каждый в отдельный сервисный класс.

Я лично в своей библиотеке unipath.php использую xpath подобный синтаксис для "вытаскивание" данных из сложных структур.
Например вот так: uni("response/response/GeoObjectCollection/featureMember/0/GeoObject/metaDataProperty/GeocoderMetaData/Address/formatted/ifEmpty('Адрес не найден')")

Не думали тоже подобный способ реализовать? Так ведь короче.

Мне кажется хорошо было бы подписать фрагменты кода: где на bash и где на python. Было бы немного удобнее. Лично я не сразу понял когда начал читать, что второй фрагмент - это уже на питоне.

Я так понял element.style.color = 'red' обрабатывается так-же как и element.style.setProperty('color', 'red'). По этому тесты на скорость не проводились такого варианта соответственно?

все эти годы план Б съедал ресурсы, которые могли пойти на развитие собственного проекта

Да, я тоже когда-то давно чувствовал такое в подобной ситуации и принимал решения сконцентрироваться на своих проектах.

Но опыт показал, что это глупость. Свои проекты жрут ресурсы нескончаемо. А провал, для них - это нормальная явление. Mой LittleLisp.js оказался никому не нужен. А самая крутая вещь UniPath.php уже 10 лет как развивается и не может развиться до стабильного релиза.

По этому работа в найме - это мой главный План А. И ресурсы в него я трачу в первую очередь. И это везение если попадается работа, где можно поразвивать свои проекты тоже.

По сути, с момента утраты зуба мы начинаем терять кость в этой области.

Так всегда же можно "подсыпать" искусственной кости и восстановить её объём. Так-что на это можно закрыть глаза.

Хорошая работа. Плюсую!
Есть люди, которым этого как раз не хватает)

Android в этом плане смотрится выигрешнее. На Java относительно легко можно запрограммировать то, что не хватает. Система достаточно открыта. С iOS в этом плане гораздо сложнее.

В телеграмме Kandinsky 3.1 вышел и похоже отключили Kandinsky 2.х. Эх, а 2.2 версия красивее всего генерировала женских персонажей по моим промптам. Грусть, печаль.

Например промпт: full body view, look at viewer, beautiful happy princess sitting on the throne, blond, blue eyes, angelic smile, no makeup, perfect body,
large breast, wide hips, very thin waist, golden ball gown dress, white sleeves, ruffles, backlight glow
Стиль: Детальное фото

Kandinsky 2.2

Kandinsky 3.1

Да, смориться неплохо, но уже что-то не то, как на мой взгляд.

Годная справочная статья. Плюсую.

Информация

В рейтинге
Не участвует
Откуда
Краснодар, Краснодарский край, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Фулстек разработчик, Веб-разработчик
Старший
ООП
Java
Python
PHP
Git
SQL
REST