Действительно ли высокоуровневые языки программирования не позволяют определенных действий умышленно?

@Etyuhibosecyu · Регистрация: 13.07.2017

Author24 — интернет-сервис помощи студентам

Речь идет не о низкоуровневых действиях, таких как прямое управление памятью, а наоборот, об ультра-высокоуровневых конструкциях. В этой теме я наткнулся на реальную ограниченность самого мощного языка современности - C# - далеко не в низкоуровневых действиях. И господин uzhsoft написал:

Сообщение от uzhsoft

ограничен и очень сильно... но это больше для того, чтобы в ногу не стрелять

Как написано на другом форуме по поводу выражения "выстрелить себе в ногу":

Это означает, что на языке можно написать команду или конструкцию, которая сломает нормальное поведение программы или системы (или будет выполняться совершенно не так, как можно было бы логически предположить), и при этом компилятор/интерпретатор это скомпилирует и не ругнется.

Каким способом возможно, например, с помощью такого кода (допустим, я напишу язык, похожий на C#, но в котором типизировать универсальным типом функцию, передаваемую в качестве параметра в другую функцию, является возможным):

Код

closed static [(typename T1, typename T2), null Function((() T1, () T2) list1, (() T1, () T2) list2, [typename TInner, Action[() TInner, () TInner]] inner_func)] MyFunc =
{
	(() T1 left_list1, () T2 right_list1) = list1;
	(() T1 left_list2, () T2 right_list2) = list2;
	inner_func(left_list1, left_list2);
	inner_func(right_list1, right_list2);
};
(() int, () string) list1 = ((1, 2, 3), ("A", "B", "C")), list2 = ((5, 10, 15), ("X", "Y", "Z"));
MyFunc(list1, list2, (x, y) => x.Add(y));

- сломать нормальное поведение программы или системы? (Вот таблица соответствий условного языка и C#.)

closed	private
typename	Рекурсивный тип, все другие типы являются его значениями
[A, B] (без типа впереди)	Dictionary<A, B>
null Function(...)	void(...) (функция, не возвращающая значения)
() T	List<T>
Type[...]	Type<...>
[A, B] = something	Это значение доступно по всем ключам словаря
list.Add	Может добавить как одно значение, так и список

(Эта тема - НЕ презентация возможностей языка. Ее суть - вопрос об ограничениях на некоторые действия в языках программирования в принципе.)
Я понимаю, что какое-то явное издевательство над программированием - нужно запрещать. Но в данном коде я не вижу ничего такого, что нарушает принципы высокоуровневого языка (как, например, goto, подстановка абсолютно любого кода в макрос с любым алфавитно-цифровым именем (таким, как if) или уже упомянутое прямое управление памятью), даже наоборот - это является не просто высокоуровневой, а ультра-высокоуровневой возможностью. Но почему же тогда эта возможность запрещена? И это в Шарпе, который должен давать другим языкам пример для подражания в плане высокоуровневости! Или, может, такая могучая корпорация Microsoft по какой-то причине не может сделать то, что, скорее всего, может любой быдлокодер, нужно только время? Или там сидят такие лентяи, которые не делают себе труда реализовать это? Или такие бездарные люди, которые не представляют себе, что так можно сделать, зато умеют воровать идеи, и пройдет пара лет после того, как я это здесь написал - и эта возможность появится? Или вы хотите сказать, что это по каким-то объективным причинам, которых я не знаю, не получится ни у кого, в том числе и у меня? Нет, мне кажется, что это ограничение было введено умышленно. Но для чего? Прошу ответить.

@Etyuhibosecyu · 14.01.2021, 09:28 **[ТС]**

Сообщение от Shamil1

Если строка не известна на момент компиляции, то это уже динамическая типизация получается.

А в Шарпе есть же тип dynamic. Почему-то не то про него все забывают, не то... Почему им не пользуются? Какие проблемы он приносит, кроме того, что нельзя проверить корректность программы на этапе компиляции? Во сколько раз, например, он медленнее - в два-три или в сотни? И может, есть еще какие-то "подводные камни"?

@Usaga · 14.01.2021, 09:34

Сообщение от Etyuhibosecyu

Почему им не пользуются?

Потому, что это динамическая типизация получается. Dynamic ввели только для работы с COM.

@Etyuhibosecyu · 14.01.2021, 09:42 **[ТС]**

Сообщение от Usaga

Потому, что это динамическая типизация получается.

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

@Usaga · 14.01.2021, 09:48

Etyuhibosecyu, я ответил почему: оно только для COM. Мешать типизации просто потому, что можно - чистой воды быдлятина.

Добавлено через 3 минуты
Вы не ответили на вопрос о задумке, которую реализуете. Фраза про тип из строки наводит на мысль о новой версии какого-то транслятора\компилятора, которая реализуется через задницу.

@Etyuhibosecyu · 14.01.2021, 09:53 **[ТС]**

Сообщение от Usaga

я ответил почему: оно только для COM.

Я прочитал. Но это не ответ на вопрос, почему конкретно этот тип плохой и использовать его - зло.

Сообщение от Usaga

Мешать типизации просто потому, что можно - чистой воды быдлятина.

А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации?

Сообщение от Usaga

Вы не ответили на вопрос о задумке, которую реализуете. Фраза про тип из строки наводит на мысль о новой версии какого-то транслятора\компилятора, которая реализуется через задницу.

Вы угадали. А как можно реализовать иначе? Только без слов в стиле того, что это никому не нужно.

@Usaga · 14.01.2021, 10:01

Сообщение от Etyuhibosecyu

Я прочитал. Но это не ответ на вопрос, почему конкретно этот тип плохой и использовать его - зло.

Почитайте про динамическую типизацию и минусы, что она несёт.

Сообщение от Etyuhibosecyu

А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации?

Такого не бывает. В принципе. Только, если компетенция на уровне плинтуса. Но это уже не проблема языка.

Сообщение от Etyuhibosecyu

Вы угадали. А как можно реализовать иначе? Только без слов в стиле того, что это никому не нужно.

Почитайте "Книгу Дракона". Там рассказывается и показывается. Если осилите. Вы пытаетесь спроецировать транслируемую программу на код собственно транслятора. Оттуда такая потребность "строки в типы" преобразовывать. Между тем, транслятор должен строить внутренее представление программы транслируемой, а все её типы должны быть только идентификаторами и метаданными к самому C# отношения не имеющими.

Бесполезно это всё расписывать тут. Читайте специальную литературу. И не пытайтесь обвинять язык в недостаточной гибкости, когда используете его неправильно.

@Shamil1 · 14.01.2021, 10:06

Etyuhibosecyu,
Вы, похоже, считаете, что чем больше "возможностей" (конструкций) предоставляет язык, тем лучше. На самом деле, наоборот, чем меньше, тем лучше (при условии, что язык позволяет эффективно решать поставленные задачи).

Возьмём, например, брелок автомобильной сигнализации с одной кнопкой, которая включает/отключает сигнализацию. А теперь добавим ещё 20 дополнительных возможностей - от открывания капота до проверки уровня топлива. Станет только хуже. Вместо одной большой кнопки, которую можно нажать, не вынимая руки из кармана, будет 20 маленьких, среди которых ещё нужно найти нужную.

С ЯП то же самое. Лишние возможности только мешают. Особенно те, которые дают возможность писать в плохом стиле.

@Usaga · 14.01.2021, 10:12

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

Добавлено через 2 минуты
Etyuhibosecyu, я вам уже сколько раз говорил: если вам что-то неудобно и где-то не хватает "мощи языка", то посмотрите как подобное делают другие. Может оказать, что решение принципиально иное. А так как плохой танцор: куда не плюнь, всё неудобно и негибко.

Алексей1153 · 14.01.2021, 10:14

Etyuhibosecyu, научись задавать вопросы в таком виде:

как мне сделать A ?
это мне нужно для того, чтобы сделать B
а это мне нужно, чтобы решить C
... и так далее, до самого корня проблемы...

в таком случае будет сильно экономиться время, так как тебе сразу подскажут, что C решается совсем иначе, и A и B - не нужны

@Etyuhibosecyu · 14.01.2021, 10:21 **[ТС]**

Сообщение от Shamil1

На самом деле, наоборот, чем меньше, тем лучше (при условии, что язык позволяет эффективно решать поставленные задачи).

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

@Usaga · 14.01.2021, 10:34

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

@Etyuhibosecyu · 14.01.2021, 10:44 **[ТС]**

Сообщение от Usaga

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

Ну, у осциллографа есть хоть и непонятные народному быдлу, но конечные, дискретные и детерминированные правила пользования. А "правила пользования" языком программирования бесконечные и детерминированы только для машины. Поэтому сравнение не совсем корректно.

@Usaga · 14.01.2021, 10:48

Сообщение от Etyuhibosecyu

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

Так и у ЯП и разработки в целом тоже. Только читать эти правила вы наотрез отказваетесь. А потом начинаете изобретать невесть что.

@Etyuhibosecyu · 14.01.2021, 10:54 **[ТС]**

Сообщение от Usaga

Так и у ЯП и разработки в целом тоже. Только читать эти правила вы наотрез отказваетесь.

Прямо они конечные, дискретные и детерминированные? Если уложатся в 64 КБ, я с удовольствием почитаю. Только если получу прямую ссылку на них и если это действительно исчерпывающие правила разработки чего угодно. Ну и естественно, если это не требует ученой степени.

@Usaga · 14.01.2021, 10:59

Etyuhibosecyu, я вам уже давал название сборника таких правил для разработки компиляторов: "Книга Дракона". Помнится, вы бросили её читать сказав, что слишком сложно и непонятно.

Сообщение от Etyuhibosecyu

Если уложатся в 64 КБ

А если нет, то продолжите велосипеды делать и жаловаться, что C# невыразительный и ничего на нём не сделать, за что бы вы ни взялись?

@Etyuhibosecyu · 14.01.2021, 11:27 **[ТС]**

Сообщение от Usaga

я вам уже давал название сборника таких правил для разработки компиляторов: "Книга Дракона".

Эта книга не проходит по трем с половиной пунктам - хоть ученой степени и не требует, но требует узкоспециализированных знаний из дискретной математики, по остальным пунктам не проходит абсолютно.

Сообщение от Usaga

А если нет, то продолжите велосипеды делать и жаловаться, что C# невыразительный и ничего на нём не сделать, за что бы вы ни взялись?

Долго думал, что ответить, но ответить нечего.

@Usaga · 14.01.2021, 11:37

Сообщение от Etyuhibosecyu

Эта книга не проходит по трем с половиной пунктам - хоть ученой степени и не требует, но требует узкоспециализированных знаний из дискретной математики, по остальным пунктам не проходит абсолютно.

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

Сообщение от Etyuhibosecyu

Долго думал, что ответить, но ответить нечего.

И не надо. Надо осознать критику и попробовать пересмотреть свои подходы к работе.

@Катафалк · 14.01.2021, 11:45

Сообщение от Etyuhibosecyu

А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации?

Компилятор сишарпа написан на сишарпе. Вывод - для написания трансляторов возможностей сишарпа абсолютно достаточно. Недостаточно только знаний у вас.

Сообщение от Etyuhibosecyu

но требует узкоспециализированных знаний из дискретной математики

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

@Usaga · 14.01.2021, 11:54

Сообщение от Etyuhibosecyu

но требует узкоспециализированных знаний из дискретной математики

Кстати, вот тоже момент. Если книга по разработке компиляторов требует каких-то знаний, которых у вас нет, то почему вы решили, что сама разработка компиляторов этих знаний не требует? И почему вы решили, что раз вы не можете этот материал осилить и всё равно берётесь за задачу, которая у вас закономерно не получается, то виноват C#, а не отсутствие у вас этих знаний? Где тут логика?

@Etyuhibosecyu · 14.01.2021, 12:18 **[ТС]**

Usaga, а вы уверены, что книга о создании собственного языка программирования называется именно "Книгой Дракона"? Что-то запрос в Google нашел бог знает что.

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 09:28 [ТС]	61
	Сообщение от Shamil1 Если строка не известна на момент компиляции, то это уже динамическая типизация получается. А в Шарпе есть же тип dynamic. Почему-то не то про него все забывают, не то... Почему им не пользуются? Какие проблемы он приносит, кроме того, что нельзя проверить корректность программы на этапе компиляции? Во сколько раз, например, он медленнее - в два-три или в сотни? И может, есть еще какие-то "подводные камни"? 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 09:34	62
	Сообщение от Etyuhibosecyu Почему им не пользуются? Потому, что это динамическая типизация получается. Dynamic ввели только для работы с COM. 0

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 09:42 [ТС]	63
	Сообщение от Usaga Потому, что это динамическая типизация получается. Динамическая типизация получается, если все типы неизвестны на этапе компиляции. А если большинство типов известны, а изредка используется dynamic, это полудинамическая типизация. Ну и допустим, даже если частично динамическая, это лучше Пайсена вследствие огромной мощи .NET. Почему же тогда этот тип упоминается только в узкоспециализированных местах, и практически никогда - на форуме? Вот о чем я спрашиваю. 0

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 09:53 [ТС]	65
	Сообщение от Usaga я ответил почему: оно только для COM. Я прочитал. Но это не ответ на вопрос, почему конкретно этот тип плохой и использовать его - зло. Сообщение от Usaga Мешать типизации просто потому, что можно - чистой воды быдлятина. А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации? Сообщение от Usaga Вы не ответили на вопрос о задумке, которую реализуете. Фраза про тип из строки наводит на мысль о новой версии какого-то транслятора\компилятора, которая реализуется через задницу. Вы угадали. А как можно реализовать иначе? Только без слов в стиле того, что это никому не нужно. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 10:01	66
	Сообщение от Etyuhibosecyu Я прочитал. Но это не ответ на вопрос, почему конкретно этот тип плохой и использовать его - зло. Почитайте про динамическую типизацию и минусы, что она несёт. Сообщение от Etyuhibosecyu А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации? Такого не бывает. В принципе. Только, если компетенция на уровне плинтуса. Но это уже не проблема языка. Сообщение от Etyuhibosecyu Вы угадали. А как можно реализовать иначе? Только без слов в стиле того, что это никому не нужно. Почитайте "Книгу Дракона". Там рассказывается и показывается. Если осилите. Вы пытаетесь спроецировать транслируемую программу на код собственно транслятора. Оттуда такая потребность "строки в типы" преобразовывать. Между тем, транслятор должен строить внутренее представление программы транслируемой, а все её типы должны быть только идентификаторами и метаданными к самому C# отношения не имеющими. Бесполезно это всё расписывать тут. Читайте специальную литературу. И не пытайтесь обвинять язык в недостаточной гибкости, когда используете его неправильно. 1

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 09:48	64
	Etyuhibosecyu, я ответил почему: оно только для COM. Мешать типизации просто потому, что можно - чистой воды быдлятина. Добавлено через 3 минуты Вы не ответили на вопрос о задумке, которую реализуете. Фраза про тип из строки наводит на мысль о новой версии какого-то транслятора\компилятора, которая реализуется через задницу. 0

@Shamil1 Модератор 3051 / 2193 / 459 Регистрация: 26.03.2015 Сообщений: 8,469
	14.01.2021, 10:06	67
	Etyuhibosecyu, Вы, похоже, считаете, что чем больше "возможностей" (конструкций) предоставляет язык, тем лучше. На самом деле, наоборот, чем меньше, тем лучше (при условии, что язык позволяет эффективно решать поставленные задачи). Возьмём, например, брелок автомобильной сигнализации с одной кнопкой, которая включает/отключает сигнализацию. А теперь добавим ещё 20 дополнительных возможностей - от открывания капота до проверки уровня топлива. Станет только хуже. Вместо одной большой кнопки, которую можно нажать, не вынимая руки из кармана, будет 20 маленьких, среди которых ещё нужно найти нужную. С ЯП то же самое. Лишние возможности только мешают. Особенно те, которые дают возможность писать в плохом стиле. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 10:12	68
	Shamil1, именно так он и считает. Когда он начинает что-то делать и у него не получается, то он делает вывод, что это язык недостаточно гибок, а не он чего-то не знает. Оттуда и потребность запилить свой язык, который будет реализовывать все возможности, которые только ему и нужны. Добавлено через 2 минуты Etyuhibosecyu, я вам уже сколько раз говорил: если вам что-то неудобно и где-то не хватает "мощи языка", то посмотрите как подобное делают другие. Может оказать, что решение принципиально иное. А так как плохой танцор: куда не плюнь, всё неудобно и негибко. 0

Алексей1153 фрилансер 5493 / 5090 / 1046 Регистрация: 11.10.2019 Сообщений: 13,314
	14.01.2021, 10:14	69
	Etyuhibosecyu, научись задавать вопросы в таком виде: как мне сделать A ? это мне нужно для того, чтобы сделать B а это мне нужно, чтобы решить C ... и так далее, до самого корня проблемы... в таком случае будет сильно экономиться время, так как тебе сразу подскажут, что C решается совсем иначе, и A и B - не нужны 1

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 10:21 [ТС]	70
	Сообщение от Shamil1 На самом деле, наоборот, чем меньше, тем лучше (при условии, что язык позволяет эффективно решать поставленные задачи). Почему-то ключевую фразу вы взяли в скобки. Перед брелком для сигнализации стоит задача включать и отключать сигнализацию, тут все понятно. А перед языком программирования стоит такая задача: с минимальными усилиями писать потенциально любую программу. Поэтому к брелку для сигнализации и к языку программирования должны использоваться разные подходы. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 10:34	71
	Etyuhibosecyu, язык программирования - инструмент. А как всяким инструментом им надо уметь правильно пользоваться. В вашем случае, почему-то, вы решили, что осциллограф сломанный, раз вы не можете им нормально воспользоваться. 0

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 10:44 [ТС]	72
	Сообщение от Usaga А как всяким инструментом им надо уметь правильно пользоваться. В вашем случае, почему-то, вы решили, что осциллограф сломанный, раз вы не можете им нормально воспользоваться. Ну, у осциллографа есть хоть и непонятные народному быдлу, но конечные, дискретные и детерминированные правила пользования. А "правила пользования" языком программирования бесконечные и детерминированы только для машины. Поэтому сравнение не совсем корректно. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 10:48	73
	Сообщение от Etyuhibosecyu Ну, у осциллографа есть хоть и непонятные народному быдлу, но конечные, дискретные и детерминированные правила пользования. Так и у ЯП и разработки в целом тоже. Только читать эти правила вы наотрез отказваетесь. А потом начинаете изобретать невесть что. 0

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 10:54 [ТС]	74
	Сообщение от Usaga Так и у ЯП и разработки в целом тоже. Только читать эти правила вы наотрез отказваетесь. Прямо они конечные, дискретные и детерминированные? Если уложатся в 64 КБ, я с удовольствием почитаю. Только если получу прямую ссылку на них и если это действительно исчерпывающие правила разработки чего угодно. Ну и естественно, если это не требует ученой степени. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 10:59	75
	Etyuhibosecyu, я вам уже давал название сборника таких правил для разработки компиляторов: "Книга Дракона". Помнится, вы бросили её читать сказав, что слишком сложно и непонятно. Сообщение от Etyuhibosecyu Если уложатся в 64 КБ А если нет, то продолжите велосипеды делать и жаловаться, что C# невыразительный и ничего на нём не сделать, за что бы вы ни взялись? 0

	14.01.2021, 12:18

Опции темы

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 11:27 [ТС]	76
	Сообщение от Usaga я вам уже давал название сборника таких правил для разработки компиляторов: "Книга Дракона". Эта книга не проходит по трем с половиной пунктам - хоть ученой степени и не требует, но требует узкоспециализированных знаний из дискретной математики, по остальным пунктам не проходит абсолютно. Сообщение от Usaga А если нет, то продолжите велосипеды делать и жаловаться, что C# невыразительный и ничего на нём не сделать, за что бы вы ни взялись? Долго думал, что ответить, но ответить нечего. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 11:37	77
	Сообщение от Etyuhibosecyu Эта книга не проходит по трем с половиной пунктам - хоть ученой степени и не требует, но требует узкоспециализированных знаний из дискретной математики, по остальным пунктам не проходит абсолютно. Не требует она математики. Там концепции и идеи вполне понятно расписаны. Несколько поколений разработчиков на ней выросло. А вам опять неудобно. Сообщение от Etyuhibosecyu Долго думал, что ответить, но ответить нечего. И не надо. Надо осознать критику и попробовать пересмотреть свои подходы к работе. 0

@Катафалк 171 / 399 / 12 Регистрация: 21.06.2019 Сообщений: 2,432
	14.01.2021, 11:45	78
	Сообщение от Etyuhibosecyu А если не потому, что можно, а потому, что это единственный выход из сложившейся на практике ситуации? Компилятор сишарпа написан на сишарпе. Вывод - для написания трансляторов возможностей сишарпа абсолютно достаточно. Недостаточно только знаний у вас. Сообщение от Etyuhibosecyu но требует узкоспециализированных знаний из дискретной математики Так а нафига вы взялись за задачу, которую абсолютно не понимаете как решать? Чем то напоминает карго-культ, когда туземцы собирали увиденные когда-то самолеты из веток и листьев в надежде, что им за это дары с неба перепадут. 0

@Usaga 12090 / 8369 / 1280 Регистрация: 21.01.2016 Сообщений: 31,547
	14.01.2021, 11:54	79
	Сообщение от Etyuhibosecyu но требует узкоспециализированных знаний из дискретной математики Кстати, вот тоже момент. Если книга по разработке компиляторов требует каких-то знаний, которых у вас нет, то почему вы решили, что сама разработка компиляторов этих знаний не требует? И почему вы решили, что раз вы не можете этот материал осилить и всё равно берётесь за задачу, которая у вас закономерно не получается, то виноват C#, а не отсутствие у вас этих знаний? Где тут логика? 0

@Etyuhibosecyu Труд вопреки насмешкам 288 / 165 / 40 Регистрация: 13.07.2017 Сообщений: 3,000 Записей в блоге: 8
	14.01.2021, 12:18 [ТС]	80
	Usaga, а вы уверены, что книга о создании собственного языка программирования называется именно "Книгой Дракона"? Что-то запрос в Google нашел бог знает что. Миниатюры 0