Proposal для Go 2 написали? :)
Возможно такой уже есть, надо искать.
Если хорошо расписать, то какой-то минимальный шанс на значения по умолчанию для структур есть.
Насчёт параметров функций по умолчанию не уверен. Не упаковывал бы
это всё в один proposal.
Если считать CLOS и вообще говоря мультиметоды, ООП, то там не будет однонаправленности, динамическая диспетчерезация будет по M аргументам.
Проблема лопаты и ямы в случае, когда вызов метода по синтаксису идентичен вызову функции (и потенциально этом может быть мультиметод, то есть полиморфизм мы не теряем), как будто бы исчезает.
Даже если сказать, что остаётся вопрос порядка аргументов, dig(shovel, tool) или dig(shovel, hole), можно найти ЯП с поддержкой именованных аргументов: dig(tool=shovel, hole=hole).
Это я к чему: ограничения конкретных ЯП очень слабо отвечают на вопрос ограничений или проблем ООП.
Вы, конечно, не про vim спрашивали, но я могу описать как происходит в моей конфигурации Emacs.
Из-за его однопоточности всё может дойти до того, что при большом количестве событий на
печать/перемещения курсора могут возникать подвисания (freeze) редактора на небольшое,
но замечаемое глазом время (0.1-0.3 секунды).
Если честно, всё равно по ощущениям более отзывчивый, чем IntelliJ IDE на достаточно мощных машинах,
а на моём ноутбуке так её лучше не запускать, рискуют на пару с браузером вогнать кого-нибудь в swap.
Но по потреблению памяти, нет, не факт, что будет проигрывать.
Описанный выше «задумчивый» Emacs даже на достаточно большом количестве немаленьких буферов
потребляет примерно 60-80Mb.
tl;dr — да, вы правы, но экстраполировать на абстрактную IDE сложно. Зависит от её кривизны.
А вы пробовали? Обычно это приятно, внести свой, пусть и небольшой, вклад в то, что ты используешь. Это может быть любимый плагин к тектовому редактору или библиотека, которая упрощает тебе твою работу.
Не факт, что это универсально и нравится каждому, но трудозатраты обычно небольшие, рисков немного. В небольшие проекты minor изменения принимают достаточно охотно.
Самый простой вид «вклада» — это исправление неточностей в документации.
Обычно их находишь, если внимательно изучаешь документацию.
Какова мотивация их править?
Если ваc эти недостатки в документации заставили потратить лишнее время,
может захотеться сделать так, чтобы другой человек не потратил этого времени.
Такие изменения отклоняют очень редко.
По-моему интересная была игра для своего времени, хороший симулятор выживания.
Там была система крафта, голод/жажда, заболевания, погодные условия, которые влияют на персонажа (если холодно — нужна одежда потеплее, если жарко — поменьше одежду и шляпу из листьев на голову).
Столько вопросов… Не смогу на каждый из них дать стоящий ответ.
Для снижения градуса категоричности: в моём понимании альтернатива —
это не то же самое, что полная замена.
Уникальность Go, если брать конкретно мой проект, в том, что он был easy pick'ом в самом начале.
За один вечер уже был на коленке написанный транслятор, который преобразовывал Go код в
S-выражения.
Компилятор либо встроит тело функции, если её тело доступно, либо вставит вызов. Когда он вставит тело функции, то ему нет разницы, была ли это маленькая функция или часть одной большой функции. Специфика встраивания сильно зависит от компилятора и от языка программирования, но в любом случае, у вас есть выбор, например, в релизе компоновать все исходники в 1 единицу трансляции и компилировать как одно целое; либо можно без этого воспользоваться LTO. В общем, я не думаю, что компилятору «сложнее».
Языки типа «жабоскрипта» в нормальных движках как минимум частично выполняются в виде нативного кода, особенно если динамичные возможности языка используются в умеренном стиле.
А в интерпретируемых языках, где нет нормального JIT, я бы о таких мелочах не сильно заботился, там в одной версии i += 1 может быть медленнее, чем ++i, а потом эта разница может быть нивелирована. Очевидную, вероятно, вещь написал…
Возможно такой уже есть, надо искать.
Если хорошо расписать, то какой-то минимальный шанс на значения по умолчанию для структур есть.
Насчёт параметров функций по умолчанию не уверен. Не упаковывал бы
это всё в один proposal.
Проблема лопаты и ямы в случае, когда вызов метода по синтаксису идентичен вызову функции (и потенциально этом может быть мультиметод, то есть полиморфизм мы не теряем), как будто бы исчезает.
Даже если сказать, что остаётся вопрос порядка аргументов,
dig(shovel, tool)илиdig(shovel, hole), можно найти ЯП с поддержкой именованных аргументов:dig(tool=shovel, hole=hole).Это я к чему: ограничения конкретных ЯП очень слабо отвечают на вопрос ограничений или проблем ООП.
Из-за его однопоточности всё может дойти до того, что при большом количестве событий на
печать/перемещения курсора могут возникать подвисания (freeze) редактора на небольшое,
но замечаемое глазом время (0.1-0.3 секунды).
Если честно, всё равно по ощущениям более отзывчивый, чем IntelliJ IDE на достаточно мощных машинах,
а на моём ноутбуке так её лучше не запускать, рискуют на пару с браузером вогнать кого-нибудь в swap.
Но по потреблению памяти, нет, не факт, что будет проигрывать.
Описанный выше «задумчивый» Emacs даже на достаточно большом количестве немаленьких буферов
потребляет примерно 60-80Mb.
tl;dr — да, вы правы, но экстраполировать на абстрактную IDE сложно. Зависит от её кривизны.
Не факт, что это универсально и нравится каждому, но трудозатраты обычно небольшие, рисков немного. В небольшие проекты minor изменения принимают достаточно охотно.
Самый простой вид «вклада» — это исправление неточностей в документации.
Обычно их находишь, если внимательно изучаешь документацию.
Какова мотивация их править?
Если ваc эти недостатки в документации заставили потратить лишнее время,
может захотеться сделать так, чтобы другой человек не потратил этого времени.
Такие изменения отклоняют очень редко.
По-моему интересная была игра для своего времени, хороший симулятор выживания.
Там была система крафта, голод/жажда, заболевания, погодные условия, которые влияют на персонажа (если холодно — нужна одежда потеплее, если жарко — поменьше одежду и шляпу из листьев на голову).
Если более локально, то есть несколько вариантов.
Некоторые даже не требуют патчинга Emacs'а.
В любом случае, это очень крупный кусок, который, возможно, когда-нибудь будет затронут.
Не факт, что мной, как и не факт, что в рамках goism.
Для снижения градуса категоричности: в моём понимании альтернатива —
это не то же самое, что полная замена.
Уникальность Go, если брать конкретно мой проект, в том, что он был easy pick'ом в самом начале.
За один вечер уже был на коленке написанный транслятор, который преобразовывал Go код в
S-выражения.
Вероятно мне стоило выражаться более аккуратно.
Тем не менее, поделитесь, к какому синтаксическому семейству вы бы отнесли Go?
Языки типа «жабоскрипта» в нормальных движках как минимум частично выполняются в виде нативного кода, особенно если динамичные возможности языка используются в умеренном стиле.
А в интерпретируемых языках, где нет нормального JIT, я бы о таких мелочах не сильно заботился, там в одной версии i += 1 может быть медленнее, чем ++i, а потом эта разница может быть нивелирована. Очевидную, вероятно, вещь написал…