Рефакторинг — надуманная проблема? Эволюция ПО — надуманная проблема???
Что значит «логика слишком сложна»? Это не меняет того, для чего этот метод предназначен. И выбор способа реализации — это всего лишь детали реализации, обусловленные ограниченностью языка.
Это статья о разрабатываемом языке, в котором применены новые идеи. Это не реклама продукта, готового к применению.
Я описал основные принципы, семантику языка, эти самые новые идеи, побуждая вас взглянуть на программирование по-новому. А синтаксис вторичен. Описание его основ я привёл лишь для того, чтобы примеры, иллюстирующие конкретные функции, были понятны.
Вторая идея o42a — это возможность разделения языковой семантики и синтаксиса. Синтаксис не обязан один-в-один соответствовать языковым сущностям, сколь бы универсальны они ни были. Синтаксис должен выражать семантику программы, а не языка программирования. Он должен быть удобен для восприятия и достаточно строг. Это задача компилятора, а не программиста, приводить текст программы к языковым сущностям.
Можно сопоставить синтаксис с представлением, а программные сущности — с моделью из парадигмы MVC. А можно назвать это DSL.
В o42a есть фразы. С их помощью можно делать вполне читаемые выражения. Что-то вроде:
Task "warn if website is down"
_every [3] minutes
_starting [date 'now']
_when [web site ["http://example.org"]: not responding] {
Notify "admin@example.org" with "Server down!"
}
_: schedule()
Можно изобразить и ещё более специфичный DSL.
Но синтаксис вторичен.Язык рассчитан не только на однократное «красивое» написание программы. Основной замысел посвящён процессу разработки, включающему рефакторинг например.
Про объекты в o42a вы не до конца поняли. Объект — это не только объект из ООП. Это и действие тоже. Так что это не то же, что обычно имеют ввиду под «всё есть объект», а на самом деле стыдливо умалчивают о множестве других сущностей. o42a в этом смысле идёт до конца. Зачем? Вот здесь я привёл пример.
«Привычнее» Вы хотели сказать. Чтобы решить понятнее или нет — нужно сначала попробовать понять.
Но вот те, кто спрашивает «зачем?» ответа не ожидают. Их всё и так устраивает. Так что ничего понимать они и не собираются. Зачем?
Не согласен.
Научные дисциплины оперируют формальными моделями, это так. Но эти модели не обладают возможностями собственного объяснения. Они замкнуты в себе. Так что письменная речь, например, в математическом доказательстве, — это не комментарии, а изложение фактов формальной модели на человеческом языке.
Что до программирования, то здесь общепринятая формальная модель отсутствует. У каждой программы она если и есть — то своя собственная. Так что программа — это объяснение сути в ней происходящего. Программа должна быть понятна читающему. Её не нужно разгадывать как головоломку. Те же, кто этому принципу не следует — поступают по-свински по отношению к товарищам по команде. Это заставляет их тратить больше времени на изучение такого кода. И это просто подло, поскольку выставляет их неэффективными разработчиками, хотя вина — на авторе такого «кода».
Вы неправильно расставили акценты. Задумайтесь: «Я не люблю программировать» не означает, что я испытываю к процессу программированию хоть какое-то неприятие. Это лишь означает, что «любви» к нему я не испытываю. Это труд. А к своему труду нужно относиться с должным уважением, иначе нужно менять сферу деятельности.
Теперь касаемо «любви». Когда-то я «любил» программировать. Мне доставлял удовольствие процесс сам по себе. Вернее сказать, удовольствие мне доставлял процесс познания. С каждым днём я учился делать новые вещи, о которых не знал, или которых не умел раньше. Это будоражило, вдохновляло. Но со временем — перестало. Процесс познания нового стал само собой разумеющей частью работы. Зато куда большее вдохновление я начал испытывать видя её результат.
Так что перефразирую: мне интереснее создавать, чем познавать. (Опять же, чтобы не быть неправильно понятым: мне нравится познавать!)
Полагаю, вопрос адресован мне?
В Вашем изложении это звучит как-то сложно. Для меня это просто термины, которых я не понимаю.
А вот пример того, что я понимаю.
Ведя разработку на Java, требуется выполнять рефакторинг. Как пример — нужно передать в метод больше параметров. А потом делать это снова. При этом набор параметров (или сам метод) в определённый момент превращается в отдельный класс, поскольку параметров становится слишком много. То есть моё изначальное решение сделать это именно методом было неверным по форме. Но неверным ли по существу? Ведь и метод, и класс — всего лишь языковые конструкции, которые в данном случае представляют одно и то же. Так зачем же мне вообще выбирать между «методам» или «классом», тратя время на выбор, а затем — на рефакторинг? Да только потому, что такова специфика языка.
И не надо говорить, мол, надо было всё продумать заранее. Кто так вообще разрабатывает? NASA?
В o42a такой проблемы нет. Есть сущность (или действие) — есть объект ей соответствующий. Форма всегда одна и та же, так что ошибок «по форме» больше нет (ну или их гораздо меньше).
Ну, очевидно, что я считаю что он «лучше». А чем — я постарался объяснить в статье. Замыслом. Основой. Практическое же сравнение невозможно, поскольку должно базироваться на конкретных примерах использования. И простыми примерчиками тут не обойтись. Нужны, как минимум, библиотеки, которых нет. Так что как только спор переходит в практическую плоскость — я безоружен. Пока что.
А какую задачу или категорию задач решает Java? C++? C#? Ruby? Python?
Языки общего назначения не зря так называются.
Есть ещё нишевые языки, вроде PHP (по крайней мере в его первоначальном замысле) или Lua. Только для них и есть такая задача.
В текущем состоянии никаких задач он не решает и решить не может. Я лишь поделился замыслом. Видимо, замысел не нашёл отклика.
Однозначно, всё было бы проще, если бы версия была 1.0, а не 0.2.4. Но, увы и ах, это пока не так.
Что значит «логика слишком сложна»? Это не меняет того, для чего этот метод предназначен. И выбор способа реализации — это всего лишь детали реализации, обусловленные ограниченностью языка.
Я описал основные принципы, семантику языка, эти самые новые идеи, побуждая вас взглянуть на программирование по-новому. А синтаксис вторичен. Описание его основ я привёл лишь для того, чтобы примеры, иллюстирующие конкретные функции, были понятны.
Как понятнее изложить?
Можно изобразить и ещё более специфичный DSL.
Но синтаксис вторичен.Язык рассчитан не только на однократное «красивое» написание программы. Основной замысел посвящён процессу разработки, включающему рефакторинг например.
Про объекты в o42a вы не до конца поняли. Объект — это не только объект из ООП. Это и действие тоже. Так что это не то же, что обычно имеют ввиду под «всё есть объект», а на самом деле стыдливо умалчивают о множестве других сущностей. o42a в этом смысле идёт до конца. Зачем? Вот здесь я привёл пример.
Но вот те, кто спрашивает «зачем?» ответа не ожидают. Их всё и так устраивает. Так что ничего понимать они и не собираются. Зачем?
Этой статьёй я хотел дать пищу для размышления, а не готовые решения.
Научные дисциплины оперируют формальными моделями, это так. Но эти модели не обладают возможностями собственного объяснения. Они замкнуты в себе. Так что письменная речь, например, в математическом доказательстве, — это не комментарии, а изложение фактов формальной модели на человеческом языке.
Что до программирования, то здесь общепринятая формальная модель отсутствует. У каждой программы она если и есть — то своя собственная. Так что программа — это объяснение сути в ней происходящего. Программа должна быть понятна читающему. Её не нужно разгадывать как головоломку. Те же, кто этому принципу не следует — поступают по-свински по отношению к товарищам по команде. Это заставляет их тратить больше времени на изучение такого кода. И это просто подло, поскольку выставляет их неэффективными разработчиками, хотя вина — на авторе такого «кода».
Вы неправильно расставили акценты. Задумайтесь: «Я не люблю программировать» не означает, что я испытываю к процессу программированию хоть какое-то неприятие. Это лишь означает, что «любви» к нему я не испытываю. Это труд. А к своему труду нужно относиться с должным уважением, иначе нужно менять сферу деятельности.
Теперь касаемо «любви». Когда-то я «любил» программировать. Мне доставлял удовольствие процесс сам по себе. Вернее сказать, удовольствие мне доставлял процесс познания. С каждым днём я учился делать новые вещи, о которых не знал, или которых не умел раньше. Это будоражило, вдохновляло. Но со временем — перестало. Процесс познания нового стал само собой разумеющей частью работы. Зато куда большее вдохновление я начал испытывать видя её результат.
Так что перефразирую: мне интереснее создавать, чем познавать. (Опять же, чтобы не быть неправильно понятым: мне нравится познавать!)
В Вашем изложении это звучит как-то сложно. Для меня это просто термины, которых я не понимаю.
А вот пример того, что я понимаю.
Ведя разработку на Java, требуется выполнять рефакторинг. Как пример — нужно передать в метод больше параметров. А потом делать это снова. При этом набор параметров (или сам метод) в определённый момент превращается в отдельный класс, поскольку параметров становится слишком много. То есть моё изначальное решение сделать это именно методом было неверным по форме. Но неверным ли по существу? Ведь и метод, и класс — всего лишь языковые конструкции, которые в данном случае представляют одно и то же. Так зачем же мне вообще выбирать между «методам» или «классом», тратя время на выбор, а затем — на рефакторинг? Да только потому, что такова специфика языка.
И не надо говорить, мол, надо было всё продумать заранее. Кто так вообще разрабатывает? NASA?
В o42a такой проблемы нет. Есть сущность (или действие) — есть объект ей соответствующий. Форма всегда одна и та же, так что ошибок «по форме» больше нет (ну или их гораздо меньше).
Языки общего назначения не зря так называются.
Есть ещё нишевые языки, вроде PHP (по крайней мере в его первоначальном замысле) или Lua. Только для них и есть такая задача.
Однозначно, всё было бы проще, если бы версия была 1.0, а не 0.2.4. Но, увы и ах, это пока не так.