Э.... извиняюсь перед автором сия, и с уважением отношусь за попытку написать, но ... все же, а где речь о диалектике ? что такое диалектика и чем она отличается от Схоластики или от Казуистики или от Софистики ?
Как бы тема не раскрыта
Вот достаточно наверно взять что это даже не совсем философия, а это инструмент - т.е. одна из форм аргументации
А самое сочное в этом - критика, и она бесконечно долгая, вот я скорее с Попером соглашусь
Критику Поппер начинает с того, что синтезсубъективен — определяется не только материалом тезиса и антитезиса, но и умами, его (этот синтез) отстаивающими[25]. Но, правильно замечая, то, что противоречия — двигатель интеллектуального прогресса и что они неизбежны, диалектики делают крайне неверный вывод, что избавляться от противоречий даже нежелательно. Это опасно, говорит Поппер, поскольку так называемая плодотворность противоречий есть просто результат нашего решения не мириться с ними[26]. Кроме того, он показывает, как из противоречия следует что угодно[en]. Примирение с противоречием обязательно приводит нас к отказу от критики, от поиска непротиворечивых теорий, синтеза, к концу рациональности и науки. Поэтому диалектическая логика, более чем годная для философского описания истории, не должна занимать фундаментальное место формального логического вывода в жизни. И уж тем более нелепо утверждать, что физическая реальность развивается диалектически, как это делает Маркс.
К. Поппер отмечает, что в диалектике неправильно употребляются логические термины, а понятия «отрицание» и «противоречие» имеют определённое логическое значение, отличное от диалектического. Такая терминология, по мнению Поппера, лишь вводит в заблуждение. Менее обманчивыми были бы термины «конфликт», «противоположная тенденция» или «противоположный интерес». А неуязвимость диалектики для критики Поппер называет чрезвычайно опасным «железобетонным» догматизмом.
Кончено о этом можно поспорить, но я не буду претендовать на звание Поппера (не дорос)
Результаты исследования показали, что жизнестойкость таких мутаций в геноме не случайна — они помогают организму сражаться с внешними вирусами. Хороший пример — серповидноклеточная анемия — одна из таких наследственных мутаций, связанная с нарушением строения белка гемоглобина. К удивлению ученых, больные, унаследовавшие мутировавшие гены от родителей, оказались более устойчивыми к малярии, чем обычные люди.
Следует помнить, однако, насколько условна эта классификация. Полезность, вредность, или нейтральность мутации зависит от условий, в котоҏыҳ живет организм. Мутация нейтральная или даже вредная для данного организма и данных условиях, может оказаться полезной для другого организма и в других условиях, и наоборот. Жуки и комары не могли знать заранее, что люди изобретут ДДТ и другие инсектициды и подготовить мутации защиты. Тем не менее, эти мутации возникали – они обнаруживаются даже в тех популяциях насекомых, которые с инсектицидами не встречались. В то время, когда насекомые не сталкивались с инсектицидами, эти мутации были нейтральными. Но как только люди стали применять инсектициды – эти мутации стали не просто полезными, они стали ключевыми для выживания. Те особи, которым по наследству досталась такая мутация, вовсе не нужная их родителям, жившим в доинсектицидную эру, приобрели колоссальное преимущество ᴨеред теми, кто такой мутации не имел.
мотивация понятна, но вот мне кажется есть несколько отклонений от общего придумывать свой синтаксис, не язык, а именно синтаксис задача не очень благородная
почему - просто большинство текущих mainstream языков по синтаксису больше похожи друг на друга, в них больше общего чем разного, а раньше это было не так
например Java и C# общие:
вызовы через круглые скобки, аргументы - разделены запятыми, присваивание слева (переменная) на право (значение) через символ равно, передача значения - вызов функции - поддается той же логике: result = fun ( arg1, arg2 ) - тоже все значения текут справа на лево: сначала аргументы в функцию, из функции в результат
это уже стало на столько естественно, что как-то меньше попадается вот этого
result := fun ( arg1, arg2 )
или
procedure( arg1, arg2, result ) - тут результат засовывается в конец и вообще не понятно становиться как построить цепочку выражений, вообще в том же bash, powershell для этого сделали вертикальную черту
тенденция использовать спец символы в именах переменных в mainstream уходит, медленно уходит PHP (да простят), там например переменные начинаются с $, а с perl там еще вроде хлеще было
языки постепенно по синтаксису упрощаются и идут в сторону лаконичности, в том же C++ и PHP вызов метода через -> (obj->method(arg,arg)) (через точку то же есть, но у них семантика разная), а уже в Java и в других поздних уже точка (obj.method(arg,arg))
убираются опциональные детали, а у вас на оборот, начинаются проблемы $ $@ @$ ' " ` ``` с таким успехом не долго дойти до bash / perl - а это уже тупик будет
я бы посмотрел на более лаконичные решения, например очень сложно из нормального языка выкинуть круглые скобки - они задают порядок вычисления, а если серьезно говорить - то структуру (AST), все остальное просто, от других вещей можно избавиться, например в Scala есть массивы, но их использование не отличается особо от функций array(item) в Scala, то же что array[item] в Java, просто по смыслу, работа с функций (fn(a)) не сильно отличается от работы с массивом (arr(a)) (при условии что функция чистая) - вот в Scala и выкинули лишнее
На мой взгляд проблема изучения языка - это не синтаксис, любой синтаксис можно запомнить (дело от пары дней до пары недель), а в усвоении структуры и синтаксис в данном случае должен помогать, а не мешать, чем меньше и полнее у вас будет синтаксис тем меньше запоминать его и больше времени останется на структуры (циклы, ветвления, функции)
Когда дойдете до определения тела функций - последовательности вычислений, то лучше сразу откинуть идею со statements и перейти к expressions, и за одно циклы while выкинуть оставить только recursion и tail recursion, я бы еще if выкинул, заменил бы на pattern-match
Дети смотрят на мир так же, как и мы, а мы смотрим примерно одинаково, но... Вот видим - точнее интерпретируем по разному. Большая часть связано с работой нашей памяти. Есть разные виды дальтонизма, например физического хаарактера, тогда люди не способны из за колбочек-палочек отличать цвет. Есть психического характера, когда они способны отличать пока смотрят, но как отводят взгляд, сразу утрачивают способность отличать. Есть такие, у которых даже память теряеться о цвете, это к тому что цвет это не константа в памяти, а постоянный процесс, где то в можечке.
Другая особенность цвета, что в социуме цвет как-то делят на дискретные части (красный, синий,...), а по факту это привнесенное культурой и местностю. Извествно по текстам что в разные эпохи люди различали разное количество цветов. В текущей культуре их обычно выделено 11 или 14 цветов, включая "серый", "пурпурный", а раньше до Р. Х. Пурпурного в обороте слов небыло.
Отчасти тоже имеет в меньшем количестве по отношению к форме. Большинство людей относится к наблюдаемому объекту, как к символу, например если что-то плоское с ножками с внизу то это стол или стул, то что обозначает. Где стул или стол - это символу функция возможности сидеть или принимать пищу. Это работает автоматом, без включения дополнительного размышления.
И совсем другое дело когда, пытаешься нарисовать старый стул, который протёрт многими родственниками и не знакомыми людьми, что его много раз чинили,и что этот стул сделан из хорошего дерева. Если в таком ракурсе смотреть на задачу художника, то этот символ становится более богатым.
Дети за частую не обладают тем опытом анализа предмета, как профессиональные художники и выделяют в рисунке важные для них свойства предметов, при том часто эти свойства другие нежели у взрослых.
По поводу статьи - норм, вполне возможны интерпретация, но я уверен что дело не только в перспективе. Я уверен что линейные перспективу и другие ее виды мы видим одинаково, и если сильно надо, то есть фотоаппарат для фиксации объективной реальности. Но художественная культура не сводиться только к фиксированию реальности, иначе фото аппарат мы бы имели где ни будь в 15 веке (привет камера Обскура). Чаще как в коммерческой, так и обычной деятельности художник привносит своё восприятие, где то усиливает, где то ослабляет.
Тот же Сезан - ему больше характерна скульптурность в живописи, он работает красками и кистьями, так словно он месит глину и из неё лепит полотно. Его полотна - это скорее мастерская скульптора. А размерность - это особенность кисти и восприятия. Его цвет в работах идёт на ровне с формой, а иногда форма доминирует над цветом. Цвет точно не явления его целью.
Ровно такая же черта и с Мадельяни, но последний ещё переосмысливает объект, утрируя черты, словно они пластичные конструкции.
Есть и другие особенности, например если дело было бы, только в перспективе, то одновременно в это же время было бы несколько Мадельяни и несколько Пекассо. Но как правило это не наблюдается в массовом явлении. Отличие Малые Галанцы, то там вообще то было массовое производство академических натюрмортов - т.е. общей перпективы, притом линейной.
так и будет, все медленно и лениво, примечательно что непостижимым образом умер flash, и нативные расширения браузеров, т.е. щас браузеры не поддерживают ActiveX и прочие штуки - т.е. это же был сговор между Google / Mozilla / MicroSoft вроде, вот точно не помню, когда... точно что после 2008. Так же по тихому убивают поддержку http, ща вроде как все должны (но не обязаны) https, убивают ftp.
Возможно когда останется один производитель браузеров, тогда компания "Добра" объявит что ведущий язык разработки для их браузер например Flutter
Нужно ли было фронтенд-разработчику знать принципы построения бэкенда и серверные технологии пять лет назад?
Это вот как так? вообще не понятен вопрос? кому знать (сеньор/джун) для чего знать (поддерживать легаси) - тогда почему варианты что мол раньше не обязательно а теперь обязательно - наверно back давно не обновляли
Возможно ли сейчас быть хорошим фронтендером, зная только HTML/CSS и JavaScript?
Тоже странно, что значит хорошим ? а давай те тогда копнем чуть по раньше чем 5 лет Фронт он вообще писался не только на Angular/React/Vue или JQuery было вообще то и Flash, AIR, JavaFx, SilverLight А я вообще жду, когда уже перейдут на WASM и у нас останется в 2040 только Chrome+WASM (RUST|TypeScript|C#|Java|Haskel - compile to -> Wasm) с поддержкой JS только как Legacy
Ввести понятие памяти, бита - это про rs и t триггеры и как строится ячейка памяти и из чего она состоит. Просто на одной булевой логике не уедешь, т.к. не понятно как эта логика может содержать вычисления. Тот же вопрос сумматора необходимо понятие бита переноса. Я может плохо смотрел, его не увидел по биты памяти.
Само понятие булевой логики, надо расширить, для взрослых читателей до вопросов физики и понятия фронта волны и устойчивой и не устойчивой системы, просто из самих логических высказываний не вытекает что в пределах логики есть память (бит информации)
Не плохо бы посвятить главу вопросу булевой логики при реализации ее в физике, те же диоды, транзисторы и т.д. в качестве примера физических воплощений привести примеры "домино" компьютер и компьютеры основанные на водных устройствах и та же машина Тюнинга в биологической клетке, не стандартные виды компьютеров это интересно. Можно отдельно разобрать логику "домино" компьютера, т.к. она на прямую не содержит И,ИЛИ,НЕ, но к ней сводиться через другие операции. Можно ещё вспомнить про компьютерные схемы из красной пыли/песка в Minecraft.
В последних главах не плохо бы разобрать заблуждения по поводу язык программирования - что они могут быть похожи на естественные языки. Пример , что язык sql, задумывался как дружественный язык для домохозяек
П.с. по мне книга должна быть интересной, с кучей примеров, если уж писать на широкую аудиторию, то нужны практические примеры, желательно такие, что бы и молодой читателей мог понять и применить (это вообще круто)
То же применение, это не обязательно только специализированные языки проектирования схем/ПЛИС или как их там... А те же симуляторы микро-схем, коих много, да хоть Minecraft.
Взять и предоставить ту же схему не в стандартном виде, а виде Minecraft блоков, потом в виде схемы пайки транзисторов или фотографии сборки схемы на монтажной плате
Можно ещё вспомнить, что многие схемы были готовы и печатались в отдельных журнал в период позднего СССР
Мне сам протокол LSP интересен, но вот толком еще не разобрался с ним.
Свое IDE - ... не, это для меня слишком, я бы на LSP остановился, свой сервер LSP для своего языка это интересно
typeof при загрузке, а не при выполнении
Про typeof.. и ссылки, тут я наверно не совсем ясно выразился, мне интересно как на уровне компилятора вы определяете тип (класс) и операции над ним (методы класса) - это как я понял класс CustomType в ваших исходниках ?
Вы выделяете фазы компиляции/трансляции (лексический анализ, синтаксический AST, вывод типов) ? то с разбегу не нашел, ScriptClass - выполняет анализ исходника в AST ?
Есть вопрос о реализации (возможно я не всю документацию посмотрел)
Есть документ по грамматике языка ? (БНФ или еще какая грамматика)
А зачем @ при вызове функции ? что бы найти целевую функцию ?
О работе typeof() - Как я понимаю тип переменной определяется в runtime - путем дополнительной ссылки на тип ? как вы выделяете свой тип (класс) от встроенных классов ?
Есть ли механизм для debug ?
Смотрели вы или нет протокол Language Server Protocol ?
Ну если безопасник занимается запретами, без объяснения, без возможности демонстрации уязвимости, то в шею его надо гнать, и имя ему - диверсант и саботажник, без обид.
Это если кратко, пару комментариев выше все точно и описали.
Ещё можно вспомнить, что имеет смысл нанять спецов, которые будут регулярно ломать сервера, назначить им большие премии за успешный взлом.
Они первые найдут брешь в вашей системе, и это будет лучше, чем нежели это найдет человек ,со злым умыслом, которого вы не знаете.
Потом, в обязательном порядке, к нему, на обучение отправлять людей, которые допустили сбой.
Тот язык который, на основе блоков (if/while/...) - это по сути не визуальные языки, а тот же текст, сомнительно представленный.
Языки на основе потока данных более интересны, хотя они более нишевые (3D движки, например blender3D)
Со сложной семанитокой стоит вспомнить, что первые языки (вроде FORTRAN) не имели рекурсии в фнукциях, а потом они появились, что мешает завести это дело в графические языки... (думаю ничего не мешает)
Здесь же момент в синтаксисе, в буквенном кодировани понятий, в графическом языке то же большой потенциал кодирования.
Обычные блочные графические языки, они скудны по выразительнсоти, по факту редко используют цвет или толщину линии, или ... о боже падующую тень / визуальные образы
Хотя наш мозг визуально очень быстро работает, и работает точно не только с 2D представлением информации, но представление о визуальной стороне, визуальном языке ... в графических представлении оставляет желать лучшего.
не плохо бы сказать что Mutex в Rust не являются реентерабельными, в Java же по умолчаю synchronized/Lock/etc... на оборот
Э.... извиняюсь перед автором сия, и с уважением отношусь за попытку написать, но ... все же, а где речь о диалектике ? что такое диалектика и чем она отличается от Схоластики или от Казуистики или от Софистики ?
Как бы тема не раскрыта
Вот достаточно наверно взять что это даже не совсем философия, а это инструмент - т.е. одна из форм аргументации
оставлю тут пару ссылок
1 https://ru.wikipedia.org/wiki/Диалектика
2 https://iphlib.ru/library/collection/newphilenc/document/HASHd77fc8e881b23a6890ced7#:~:text=АРГУМЕНТАЦИЯ – способ подведения основания под,кого-либо посредством значимых аргументов.
А самое сочное в этом - критика, и она бесконечно долгая, вот я скорее с Попером соглашусь
Кончено о этом можно поспорить, но я не буду претендовать на звание Поппера (не дорос)
печально то, что категории Клейсли - вообще не раскрыты в статье
Странный автор, сравнивать технологии которые выполняют разные задачи, так же можно сравнить теплое с мягким
Почему вредные наследственные мутации не исчезают в процессе эволюции и даже приносят пользу
ЗНАЧЕНИЕ МУТАЦИЙ В ЭВОЛЮЦИИ ЖИВОГО МИРА
мотивация понятна, но вот мне кажется есть несколько отклонений от общего
придумывать свой синтаксис, не язык, а именно синтаксис задача не очень благородная
почему - просто большинство текущих mainstream языков по синтаксису больше похожи друг на друга, в них больше общего чем разного, а раньше это было не так
например Java и C# общие:
вызовы через круглые скобки, аргументы - разделены запятыми, присваивание слева (переменная) на право (значение) через символ равно, передача значения - вызов функции - поддается той же логике: result = fun ( arg1, arg2 ) - тоже все значения текут справа на лево: сначала аргументы в функцию, из функции в результат
это уже стало на столько естественно, что как-то меньше попадается вот этого
result := fun ( arg1, arg2 )
или
procedure( arg1, arg2, result ) - тут результат засовывается в конец и вообще не понятно становиться как построить цепочку выражений, вообще в том же bash, powershell для этого сделали вертикальную черту
тенденция использовать спец символы в именах переменных в mainstream уходит, медленно уходит PHP (да простят), там например переменные начинаются с $, а с perl там еще вроде хлеще было
языки постепенно по синтаксису упрощаются и идут в сторону лаконичности, в том же C++ и PHP вызов метода через -> (obj->method(arg,arg)) (через точку то же есть, но у них семантика разная), а уже в Java и в других поздних уже точка (obj.method(arg,arg))
убираются опциональные детали, а у вас на оборот, начинаются проблемы $ $@ @$ ' " ` ``` с таким успехом не долго дойти до bash / perl - а это уже тупик будет
я бы посмотрел на более лаконичные решения, например очень сложно из нормального языка выкинуть круглые скобки - они задают порядок вычисления, а если серьезно говорить - то структуру (AST), все остальное просто, от других вещей можно избавиться, например в Scala есть массивы, но их использование не отличается особо от функций array(item) в Scala, то же что array[item] в Java, просто по смыслу, работа с функций (fn(a)) не сильно отличается от работы с массивом (arr(a)) (при условии что функция чистая) - вот в Scala и выкинули лишнее
На мой взгляд проблема изучения языка - это не синтаксис, любой синтаксис можно запомнить (дело от пары дней до пары недель), а в усвоении структуры и синтаксис в данном случае должен помогать, а не мешать, чем меньше и полнее у вас будет синтаксис тем меньше запоминать его и больше времени останется на структуры (циклы, ветвления, функции)
Когда дойдете до определения тела функций - последовательности вычислений, то лучше сразу откинуть идею со statements и перейти к expressions, и за одно циклы while выкинуть оставить только recursion и tail recursion, я бы еще if выкинул, заменил бы на pattern-match
Сами филосовы не относят философию к науке, а ставят ее обычно выше
Да и математикам нобелевку не дают
Дети смотрят на мир так же, как и мы, а мы смотрим примерно одинаково, но... Вот видим - точнее интерпретируем по разному. Большая часть связано с работой нашей памяти. Есть разные виды дальтонизма, например физического хаарактера, тогда люди не способны из за колбочек-палочек отличать цвет. Есть психического характера, когда они способны отличать пока смотрят, но как отводят взгляд, сразу утрачивают способность отличать. Есть такие, у которых даже память теряеться о цвете, это к тому что цвет это не константа в памяти, а постоянный процесс, где то в можечке.
Другая особенность цвета, что в социуме цвет как-то делят на дискретные части (красный, синий,...), а по факту это привнесенное культурой и местностю. Извествно по текстам что в разные эпохи люди различали разное количество цветов. В текущей культуре их обычно выделено 11 или 14 цветов, включая "серый", "пурпурный", а раньше до Р. Х. Пурпурного в обороте слов небыло.
Отчасти тоже имеет в меньшем количестве по отношению к форме. Большинство людей относится к наблюдаемому объекту, как к символу, например если что-то плоское с ножками с внизу то это стол или стул, то что обозначает. Где стул или стол - это символу функция возможности сидеть или принимать пищу. Это работает автоматом, без включения дополнительного размышления.
И совсем другое дело когда, пытаешься нарисовать старый стул, который протёрт многими родственниками и не знакомыми людьми, что его много раз чинили,и что этот стул сделан из хорошего дерева. Если в таком ракурсе смотреть на задачу художника, то этот символ становится более богатым.
Дети за частую не обладают тем опытом анализа предмета, как профессиональные художники и выделяют в рисунке важные для них свойства предметов, при том часто эти свойства другие нежели у взрослых.
По поводу статьи - норм, вполне возможны интерпретация, но я уверен что дело не только в перспективе. Я уверен что линейные перспективу и другие ее виды мы видим одинаково, и если сильно надо, то есть фотоаппарат для фиксации объективной реальности. Но художественная культура не сводиться только к фиксированию реальности, иначе фото аппарат мы бы имели где ни будь в 15 веке (привет камера Обскура). Чаще как в коммерческой, так и обычной деятельности художник привносит своё восприятие, где то усиливает, где то ослабляет.
Тот же Сезан - ему больше характерна скульптурность в живописи, он работает красками и кистьями, так словно он месит глину и из неё лепит полотно. Его полотна - это скорее мастерская скульптора. А размерность - это особенность кисти и восприятия. Его цвет в работах идёт на ровне с формой, а иногда форма доминирует над цветом. Цвет точно не явления его целью.
Ровно такая же черта и с Мадельяни, но последний ещё переосмысливает объект, утрируя черты, словно они пластичные конструкции.
Есть и другие особенности, например если дело было бы, только в перспективе, то одновременно в это же время было бы несколько Мадельяни и несколько Пекассо. Но как правило это не наблюдается в массовом явлении. Отличие Малые Галанцы, то там вообще то было массовое производство академических натюрмортов - т.е. общей перпективы, притом линейной.
так и будет, все медленно и лениво, примечательно что непостижимым образом умер flash, и нативные расширения браузеров, т.е. щас браузеры не поддерживают ActiveX и прочие штуки - т.е. это же был сговор между Google / Mozilla / MicroSoft вроде, вот точно не помню, когда... точно что после 2008. Так же по тихому убивают поддержку http, ща вроде как все должны (но не обязаны) https, убивают ftp.
Возможно когда останется один производитель браузеров, тогда компания "Добра" объявит что ведущий язык разработки для их браузер например Flutter
В целом, политика оной компании к тому движется
Нужно ли было фронтенд-разработчику знать принципы построения бэкенда и серверные технологии пять лет назад?
Это вот как так? вообще не понятен вопрос? кому знать (сеньор/джун) для чего знать (поддерживать легаси) - тогда почему варианты что мол раньше не обязательно а теперь обязательно - наверно back давно не обновляли
Возможно ли сейчас быть хорошим фронтендером, зная только HTML/CSS и JavaScript?
Тоже странно, что значит хорошим ? а давай те тогда копнем чуть по раньше чем 5 лет
Фронт он вообще писался не только на Angular/React/Vue или JQuery
было вообще то и Flash, AIR, JavaFx, SilverLight
А я вообще жду, когда уже перейдут на WASM и у нас останется в 2040 только Chrome+WASM (RUST|TypeScript|C#|Java|Haskel - compile to -> Wasm) с поддержкой JS только как Legacy
Извините, прострел предыдущую статью по фронт сигнала там есть.
Предложение
Ввести понятие памяти, бита - это про rs и t триггеры и как строится ячейка памяти и из чего она состоит. Просто на одной булевой логике не уедешь, т.к. не понятно как эта логика может содержать вычисления. Тот же вопрос сумматора необходимо понятие бита переноса. Я может плохо смотрел, его не увидел по биты памяти.
Само понятие булевой логики, надо расширить, для взрослых читателей до вопросов физики и понятия фронта волны и устойчивой и не устойчивой системы, просто из самих логических высказываний не вытекает что в пределах логики есть память (бит информации)
Не плохо бы посвятить главу вопросу булевой логики при реализации ее в физике, те же диоды, транзисторы и т.д. в качестве примера физических воплощений привести примеры "домино" компьютер и компьютеры основанные на водных устройствах и та же машина Тюнинга в биологической клетке, не стандартные виды компьютеров это интересно. Можно отдельно разобрать логику "домино" компьютера, т.к. она на прямую не содержит И,ИЛИ,НЕ, но к ней сводиться через другие операции. Можно ещё вспомнить про компьютерные схемы из красной пыли/песка в Minecraft.
В последних главах не плохо бы разобрать заблуждения по поводу язык программирования - что они могут быть похожи на естественные языки. Пример , что язык sql, задумывался как дружественный язык для домохозяек
П.с. по мне книга должна быть интересной, с кучей примеров, если уж писать на широкую аудиторию, то нужны практические примеры, желательно такие, что бы и молодой читателей мог понять и применить (это вообще круто)
То же применение, это не обязательно только специализированные языки проектирования схем/ПЛИС или как их там... А те же симуляторы микро-схем, коих много, да хоть Minecraft.
Взять и предоставить ту же схему не в стандартном виде, а виде Minecraft блоков, потом в виде схемы пайки транзисторов или фотографии сборки схемы на монтажной плате
Можно ещё вспомнить, что многие схемы были готовы и печатались в отдельных журнал в период позднего СССР
Мне сам протокол LSP интересен, но вот толком еще не разобрался с ним.
Свое IDE - ... не, это для меня слишком, я бы на LSP остановился, свой сервер LSP для своего языка это интересно
Про typeof.. и ссылки, тут я наверно не совсем ясно выразился, мне интересно как на уровне компилятора вы определяете тип (класс) и операции над ним (методы класса) - это как я понял класс CustomType в ваших исходниках ?
Вы выделяете фазы компиляции/трансляции (лексический анализ, синтаксический AST, вывод типов) ? то с разбегу не нашел, ScriptClass - выполняет анализ исходника в AST ?
Есть вопрос о реализации (возможно я не всю документацию посмотрел)
Есть документ по грамматике языка ? (БНФ или еще какая грамматика)
А зачем @ при вызове функции ? что бы найти целевую функцию ?
О работе typeof() - Как я понимаю тип переменной определяется в runtime - путем дополнительной ссылки на тип ? как вы выделяете свой тип (класс) от встроенных классов ?
Есть ли механизм для debug ?
Смотрели вы или нет протокол Language Server Protocol ?
Поясните , я не в курсе, чем Стьюдент не угодил?
Ну если безопасник занимается запретами, без объяснения, без возможности демонстрации уязвимости, то в шею его надо гнать, и имя ему - диверсант и саботажник, без обид.
Это если кратко, пару комментариев выше все точно и описали.
Ещё можно вспомнить, что имеет смысл нанять спецов, которые будут регулярно ломать сервера, назначить им большие премии за успешный взлом.
Они первые найдут брешь в вашей системе, и это будет лучше, чем нежели это найдет человек ,со злым умыслом, которого вы не знаете.
Потом, в обязательном порядке, к нему, на обучение отправлять людей, которые допустили сбой.
Вообще странная позиция сеньоров, устраиваться на работу и не проходить элементарные тесты связанные с работой.
Это может говорить о большом ЧСВ, тогда сразу на месте компании я бы подумал о надобности такого работника.
Другой момент, что что то с образованием и подготовленной кадров у нас ж… в отрасли
Вообще профи обычно видно по сравнению речи и как он рассуждает на технические темы, тут и без кодирования можно.
Можно элементарно задать вопросы из текущей работы, которые не имеют однозначного хорошего решения и посмотреть на то как человек будет отвечать.
Да в принципе возможна, есть два видео, где показаны не стандартные модели визуальных языков
1) https://youtu.be/mdYfFDJCDHc
2) https://youtu.be/Ps3mBPcjySE
Но и не стоит отбрасывать пару фактов
Тот язык который, на основе блоков (if/while/...) - это по сути не визуальные языки, а тот же текст, сомнительно представленный.
Языки на основе потока данных более интересны, хотя они более нишевые (3D движки, например blender3D)
Со сложной семанитокой стоит вспомнить, что первые языки (вроде FORTRAN) не имели рекурсии в фнукциях, а потом они появились, что мешает завести это дело в графические языки... (думаю ничего не мешает)
Здесь же момент в синтаксисе, в буквенном кодировани понятий, в графическом языке то же большой потенциал кодирования.
Обычные блочные графические языки, они скудны по выразительнсоти, по факту редко используют цвет или толщину линии, или ... о боже падующую тень / визуальные образы
Хотя наш мозг визуально очень быстро работает, и работает точно не только с 2D представлением информации, но представление о визуальной стороне, визуальном языке ... в графических представлении оставляет желать лучшего.
Ну глупо было бы говорить, что это не возможно.
О понятиях, не уже ли вы хотите сказать что в графических языках отсуствуют понятия как цикл, переменная, ветвление ?
Я например не считаю что это понятия относятся текстовым языкам или графическим языкам, они вне этих языков...
Такая же история и со сложными структурами данных
А текстовый или графическияй язык программирования - это лишь способ представить программу
А вот на сколько это удобный способ удобен и выразителен, это отдельный разговор
Это возможно, но сложно... объяснение почему https://habr.com/ru/post/599329/comments/#comment_23910815