>>08830

>"думают типами", а ньюфаги думают "названиями переменных"

Тип данных может поменяться вместе с задачей, а название переменной меняется не так часто. Скажем, у тебя есть счётчик денег, который ты создал сначала как float, обосрался от ошибок с округлением и резко переделал на int, но потом узнал, что в твоём языке поддерживаются числа с фиксированной точкой, и снова переделал. То есть тип поменялся два раза, а название переменной осталось без изменений. Или ты сначала сделал индексы в форме строковых констант, обосрался от того, как долго происходит сравнение, переписал на int, потом подумал-подумал и переписал на enum, а потом обнаружил StringName и снова переписал на строки, но теперь без замедления. Опять - имя не поменялось, а тип поменялся 2-3 раза. Потому что задача строится как "что нам нужно", а не "через что это имплементировать" - нам нужны "деньги" или "индексы", а через какие типы данных эти вещи будут реализовываться - дело десятое. Ты не можешь контраргументировать в стиле "олдфаг не будет ошибаться" - во-первых, это лишь означает, что он подорвался на этом в прошлом, во-вторых, не допускает ошибок только тот, кто ничего не делает. Лучше пусть точная машина следит за ошибками, чем человек грузит своё wetware лишними самопроверками.

>сначала думаешь какой результат получить, а уже потом что закинуть в коробку

Сначала ты думаешь "что требуется сделать" - это глагол-название действия, который звучит наподобие "переварить"; потом ты думаешь "с чем это требуется сделать" - это объекты, над которыми действие производится, типа "еда", потом ты выбираешь тип этих объектов - "еда" (в данном случае совпадает, но может быть нам нужен только "фастфуд" или "здоровая пища"?), а только потом определяешь, что твоё действие в оставит после себя - "говно", или "обёртку", или "ничего", если у тебя 100% КПД пищеварения, способное переварить всё, включая обёртку. Было бы странно начинать описание своего действия с того, что тебе "нужен производитель говна", или "нужен производитель пустых обёрток", или "ничего не нужно, просто пустота", и только потом давать имя этому действию. Нет, соглашусь, что иногда тебе и правда необходим абстрактный "производитель говна", а не действие с объектами, но это специфичный случай.

>>08831

>скобочек пугаешься

Они выглядят некрасиво и их труднее отличить от других видов скобок со слабым зрением и высоким PPI. На моём текущем мониторе я даже в очках пимпочки на "{}" не вижу, они выглядят как нечто среднее между "[]" и "()", поэтому с первого взгляда даже не понять, что там на самом деле. А "begin end" или отступы от края экрана видно сразу, даже без очков, даже при мелком шрифте с высоким PPI...

>Люди пытались сделать естественный язык, но всегда получалась какая-то жопа

Не знаю, о какой "жопе" ты говоришь, но подумай сам, что лучше:

>for Child in GetChildren do Child.Work; // Pascal

>for child in get_children(): child.work() # GDScript

>foreach (Node child in GetChildren()) { child.Work(); } // C#

>for (Node child: getChildren()) { child->work() } // C++

И т.д. Абсолютное превосходство Pascal очевидно - тебе не нужны ни "{}", ни "()", ни даже ":", и весь твой код читается как проза: "для каждого ребёнка из полученного списка детей приказать ребёнку сделать работу". Твой взгляд не "спотыкается" об избыточные спецсимволы и указатели типов. Просто и изящно.

>потому что парсер удобнее писать

Тогда почему не FORTH? Минимальная FORTH-машина умещается в 340 байт и это полноценный язык, способный с легкостью конкурировать с C/C++ по производительности и работать на любом железе без операционной системы. Его можно даже в древние чипы BIOS засунуть, целиком... ещё когда в них не запихивали аж десятки мегабайт под обновления. А если писать ОС, то FORTH-машина умещается в загрузочный сектор дискеты (512 байт) - и это всё, что тебе нужно, дальше только читать код ОС.

>Ты думаешь эти люди смогут написать ядро шарпов?

Пффф, обыкновенные "носочки программиста". Ты что, не надеваешь такие, когда код пишешь? А вдруг простудишься? У программиста комп мощный, сосёт как пылесос - и ветер прям по ногам дует. Тут без носочков не попрограммируешь никак. В полосочку или однотонные - это уже дело вкуса, не придирайся. Борода и длинные волосы - это тоже для теплоизоляции и терморегуляции головы. А в юбке мошонка не сдавливается и не перегревается... Не понимаю, почему у нас какие-то предрассудки против юбок - вот по какой такой причине бабам с пустой промежностью можно юбку, а мужики вынуждены сдавливать себе всё самое нежное и чувствительное, что природа специально вынесла наружу для охлаждения? У тебя никогда яичко не перекручивалось из-за того, что ногой в грубых штанах неудачно двинул? Это супер-больно. А в одних трусах не попрограммируешь по той же причине, по которой нельзя программировать без носков. Нормальные, здоровые, счастливые программисты в своей классической рабочей одежде.

И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...

>>09081

>Ну хотя бы паб разреши?

На чужой лобок (pubis) не разливай фондюк (fondue).

>>09083
Опять ты какой-то велосипед с квадратными колёсами изобретаешь...

Начнём с вопроса: зачем нужны эти public/private теги? Чтобы компилятор/IDE могла бы как-то сообщить другому программисту или нам-из-будущего, что вот эту вот фичу дёргать можно, а вот эту фичу дёргать нельзя/лучше не стоит. Ключевое слово - сообщить, так как запретить мы ему ничего не можем: желающий может просто залезть в исходники и переделать любой private в public, если ему это очень надо. Это просто такая условность, как запись зАбОрЧиКоМ или з_м_е_й_к_о_й, она нужна только для визуального ориентирования программиста на местности.

Далее, что нам важнее - public или private? Если мы пишем какой-то код, мы хотим его откуда-то вызывать, не так ли? Потому что невызываемый код нам нафиг не нужен. И даже если нам нужна только 1 точка доступа, мы можем захотеть получить доступ к чему-то кроме этого, например, в качестве теста или временного костыля-заплатки (впрочем, нет ничего более постоянного, чем временное). Поэтому очевидно, что начинать нужно с public, а как-то помечать только private.

Значит, нужен какой-то визуальный маркер для private, а public подразумевается по умолчанию. Почему бы... не начинать название со знака подчёркивания? Вот у нас есть eat(), который мы вызываем снаружи, а может быть _puke(), который вызывается изнутри автоматически, если нас накормили слишком сильно. Видишь, как просто? Всего один символ - и мы уже с первого же взгляда видим, что этот метод должен вызываться только изнутри класса - это его кишки.

Теперь мы можем настроить IDE так, чтобы она не выводила в качестве подсказки после "." поля, начинающиеся с "_", или загоняла их куда-нибудь подальше в конец списка. Помним о том, что мы не можем никому ЗАПРЕТИТЬ обращение, т.к. всегда можно поменять исходный код, и также помним, что иногда мы всё-таки хотим залезть в чьи-то кишки снаружи. Поэтому если кто-то и написал что-то вроде "person._puke()" - пускай оно выполняется, не проблема. Но главное - мы сразу видим, что этот код - костыль/заплатка, т.к. обращается к чужим кишкам - "_" в имени, и поэтому в будущем этот код нужно будет как-то переделать (отрефакторить программу).

И ты можешь не верить, но в Godot/GDScript это уже давно так принято и многими используется.

>>09091
Как-то вяло троллишь, старайся лучше.

>Километры кода с кучей модификаторов были ошибкой

Не путай айти энтерпрайз с их тысячами классов для тривиальной операции и суровый инди-соло-хобби-геймдев - бессмысленный и беспощадный, где запах свободы состоит из месячной немытости и смешивается с code smells.

>ввёл @abstract - это буквально шаг назад

Abstract нужен для наследования от общего предка-пустышки, он полезен в качестве предупреждения ошибок.

Задача: нужно 5 классов с одной функцией, у каждого своя реализация. Создаём класс-заглушку с чем-то типа:

>func do_something_generic(...args) -> GenericResult: return null

И в каждом потомке делаем то же самое, но вместо null возвращаем что-то полезное. Ноооо... спустя полгода решили добавить 6-й класс и ЗАБЫЛИ запилить эту функцию. Наш код валиден, проект запускается и никаких ошибок не выводит. Мы тестируем (если не забыли тщательно протестировать), и где-то через полчаса мы ВНЕЗАПНО натыкаемся на "whatever is null", из-за чего весь проект ломается. Приходится разбираться, что это и где нужно доделывать. Мы могли бы добавить самим-себе-из-будущего вот такое простое предупреждение:

>func do_something_generic(...args) -> GenericResult: assert(false, "implement this first"); return null

Но оно не вызовется, пока код не дойдёт до этой строчки, т.е. опять же тратим полчаса на тест. А вот если мы сообщаем компилятору заранее "это абстрактная функция, если ты её видишь - сообщи мне, что я забыл сделать реализацию этой функции в дочернем классе" - он предупредит нас сразу же, как только мы нажмём F5, и мы не будем тратить кучу времени на тестирование того, что в принципе не способно сработать по причине отсутствия.

Это не касается public/private, потому что обращение к private извне само по себе не влечёт к немедленным ошибкам. Конечно, код запутывается, превращается в "спагетти", копится "технический долг", но в общем и целом такой вызов может решать какую-то сиюминутную проблему (для хотфикса релизнутой с багом игры в ночь после релиза, например), поэтому этого следует избегать в нормальном коде, но ради "хорошей практики" не стоит засорять синтаксис языка, предназначенного для быстрого прототипирования игровых механик и склеивания различных API друг с другом.

>>09105

>Подчёркивания в начале имён мне лично не нравятся.

Эстетически? А мне вот кривые скобки не нравятся эстетически...

Ну, ладно, допустим, нужно твёрдо и чётко обозначить private. Почему бы не сделать это сразу для целого блока кода? Вот так:

>class MyObject extends Object:

>_ var public1: int

>_ var public2: float

>_ func create() -> MyObject: ...

>_ func do_at_public(): pass

>@private_part

>_ var private1: string

>_ var private2: Array

>_ func _ready(): pass

>_ func _process(): pass

>_ func do_in_private(): pass

>_ func _on_timer_timeout(): pass

>class MyOtherObject: ... # начался другой объект - приватная часть предыдущего завершена и закрыта, дальше снова публичное

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

Если честно, я бы ещё блоки var и type вернул из Pascal в GDScript. Устал уже писать каждый раз var, const, enum и всё такое...
Алсо было бы полезно объединить все @export и @onready в один большой блок, чтоб не писать на каждой строке заново...
Да и, если честно, слово "func" совсем не обязательно каждый раз писать, если по заголовку понятно, что это функция...

>>09126

>в расте

Я не знаю, что у вас там в этом вашем растишке, я его даже не пробовал. Увидел уродливый синтаксис и сразу пропустил.

>>09127

>дилемма между удобством и эффективностью

Если ты пробовал создать свой язык программирования с нуля (как делал я), то знал бы, что удобство языка можно повышать без компроментации эффективности результирующего кода. Да, время компиляции может возрасти. Да, могут быть неочевидные конструкции, которые компилятор может сделать не так, как ожидает программист. Но результирующий машинный код никак не должен зависеть от того, как выглядит исходный код языка со стороны программиста. И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор, пока он не пытается создать прошивку микроконтроллера с 16 КБ памяти на всё про всё и выполнить код в реальном времени как в какой-нибудь космической ракете. Большинство "неудобств" в существующих языках происходят не от "эффективности", а из-за необходимости поддерживать старый, давным-давно написанный код, т.е. чтобы твой "Компилятор v69.0" мог понять код, написанный во времена "Компилятор v0.01". Другими словами, кто-то когда-то сделал не слишком правильное решение, другие программисты были вынуждены применять это решение на практике, написав тонны кода, а когда нашли более правильное решение, оказалось, что нельзя просто взять и кинуть миллионы строк кода, полагающиеся на старое неправильное решение. Так языки и становятся уродливыми и неудобными. Ну, а большинство современных поделок зумеров - это буквально каргокульт, подобно создателям "убийцы ГТА" и т.п. - они способны написать рабочий код, но не понимают дизайнерской работы, которая стояла за созданием старых вещей, лишь копируя внешний вид.

Вот, кстати, наглядный пример карго-культиста в его естественном состоянии: >>09128

>что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).

Чувак в набедренной повязке на голое тело увидел "свап-оптимизации" в какой-нибудь книжке, и думает, что это какая-то священная техника, которая должна ускорять любой код быстрее скорости света, но его иллюзии разбиваются о суровую реальность, в которой реальная работа, требуемая для вызова функции интерпретатором в дебаг-режиме требует от компьютера больше, чем уже давно оптимизированный алгоритм, работающий в виде машинного кода на том же компьютере. То есть он буквально собрал "самолёт" из сухой травы и собранных палочек, танцует вокруг него и не понимает, почему с неба не падают большие ящики с провиантом.

>>09129

>Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм.

Это совсем другие "тысячи классов": https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

>Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.

Делали. Нет, не чужды, но и не нужны (не обязательны - жить можно и без них).

>>09150
Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.

>>09181

>Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.

Ну, насколько мне известно, GDScript позволяет писать весь код в одну строку. Достаточно добавить ";" где нужно.

>>09193

>А нафига ты точку в конце приложения ставишь?

Потому что он пишет несколько предложений на одной строке, и, кроме того, переносы строк (символы перехода на новую строку) в браузере для человеческого взгляда не видны явно, потому даже с переносами строк без точки или точки с запятой нелегко понять, где кончается одно предложение и начинается другое. С кодом всё иначе: код ты пишешь и читаешь через IDE, в которой переносы строк чётко обозначаются, а для компилятора/интерпретатора символы переноса строк видны так же, как и любые другие символы.

>Он нефига не знает, все его знания стоят времени компиляции.

Ты противоречишь сам себе в одном предложении... И что с того, что "стоят времени компиляции"? Компилируешь код ты один раз, а пользоваться результатом компиляции твои пользователи будут многие годы. Кроме того, медленные компиляторы - это не проблема дизайна языка, это проблема оптимизации компилятора. Если у тебя компилятор на JavaScript написан и выполняется через Electron, не нужно жаловаться, что он медленный, и тем более не нужно ломать удобство синтаксиса языка ради ускорения компиляции.

>Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.

Ты серьёзно нас путаешь? Лол. Или я тебя чем-то так обидел, что ты меня теперь в каждом анонимусе здесь видишь? Расслабься, я не пытаюсь тебя обидеть или что-то вроде. Я только люблю спорить на всякие темы... это своего рода форумная игра.

>Это выглядит крайне не профессионально

Я никогда не называл себя профессионалом, и мы не на профессиональном форуме сидим, а на форуме хоббистов-самоучек.

>возмущаться что у машины руль с лева, а не по середине

Ты же в курсе, что есть машины с рулём по центру?.. А теперь представь, что у тебя в твоей личной машине висит книга по ПДД и специальная механическая рука бьёт тебя по лицу каждый раз, когда ты не зачитываешь вслух цитату из этой книги перед тем, как совершить описанное действие. Например, захотел повернуть направо? Сначала полистай книгу, прочитай вслух что-то наподобие "перед поворотом убедитесь, что дорога свободна, нет запретительных сигналов, и у вас включён поворотный сигнал", и только после чтения этой мантры ты можешь начать поворачивать, а если забудешь прочитать мантру - механическая рука разобьёт тебе лицо. И огромная толпа автомобилистов с разбитыми лицами защищает этот механизм, объясняя тебе:

>Как можно человеку что-то объяснить если он возмущается на механизм битья по лицу? Это как возмущаться что жидкое ешь ложкой, а твёрдое ешь вилкой. Наверное механизм битья по лицу для чего-то нужен, да?

>Если такой умный, собери свой парсер

Я уже делал несколько разных парсеров своих личных языков, мне пока достаточно.

>но абстракции как текли - так и текут

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

>>09233

>Никогда не копипастил код с сайта или из чатбота

Аргумент уровня "никогда не пытался чистить уши кухонным ножом?" - сам себя поранил, а жалуешься на производителей ножей...

>>09249
Лол, давайте ещё начнём жаловаться на то, что нужно ПРОБЕЛ нажимать.

>Почему нас заставляют нажимать ПРОБЕЛ? Можно ведь писать не просто в одну строчку, но и без пробелов! Ведь пробел после точки с запятой не нужен. И после "=", "+" и т.д. Но язык всё равно устроен так, что иногда приходится жать пробел. Это так плохо! Ненавижу пробелы! Хочу писать "a in b" и "a is b" без пробелов, чтобы компилятор сам догадывался, что значит "ainb" и "aisb", а то я на нажатие пробела драгоценные наносекунды трачу, которые мог потратить на просмотр порнушки или, например, мастурбацию.

>>09937 >>09951
Ты, блин, даже не описал игру, какой вид камеры.
Читай https://ru.wikipedia.org/wiki/Проблема_XY

По факту, ты сам себе проблему нашёл. Нафига тебе неполноценные двери, которые не вписываются в 2-4 отдельных тайла? Большинство тайловых игр имеют определённый размер тайла: 1 тайл = ноги героя, а 2 = полный рост, и соответственно все двери 2 тайла и перекрывают РОВНО два тайла пола и стен.

Но ладно, если тебе прям не терпится двери самых разнообразных форм, включая круглые, сердечки, зигзагообразные, и множество других, делай так:
1. Нода с кастомным скриптом, типа:

>@tool

>class_name Door extends Sprite2D

>@export_group("Textures", "texture_")

>@export var texture_door: Texture2D

>@export var texture_wall: Texture2D

2. В потомках ноды такая фигня:

>SubViewport

>_ Wall: Sprite2D

>_ Door: Sprite2D

Можешь создавать их в _ready скрипта.
3. Настраиваешь всё через код скрипта.
4. Используешь SubViewportTexture в корне.
Да, это может быть неэффективно, если у тебя там несколько тысяч одинаковых дверей с одинаковыми стенами (нафига тогда ты этим занялся?), но ты ещё недоделал игру, так что рановато оптимизировать... А доделаешь, заметишь проблему - вот тебе план Б:
1. Скрипт хранит Resource с Dictionary:

>class_name DoorDB extends Resource

>var key_count: int

>var keys: Dictionary[Sprite2D, Dictionary]

2. Когда юзер вбивает новый спрайт-дверь или стену, проверяем эту базу дверей, и если не находим пару, генерируем новую текстуру с помощью SubViewport:

>func get_walled_door(door: Sprite2D, wall: Sprite2D) -> Sprite2D:

>_ if door not in keys:

>_ _ keys[door] = {}

>_ if wall not in keys[door]:

>_ _ keys[door][wall] = generate_walled_door(door, wall)

>_ return keys[door][wall]

3. Функция "generate_walled_door" временно создает SubViewport с двумя спрайтами, делает "скриншот" и оставляет после себя только статичную текстуру (с прозрачной дыркой под пол, естественно).
Теперь у тебя эффективный генератор + хранилище вероятных комбинаций дверей, который эффективно использует и диск, и RAM, и ЦПУ/ГПУ, адаптируясь к конкретным условиям игры и данных. Без шейдеров!