Где можно прочитать про всю суть ЯПов под капотом?

Question

[werwer]

Интересуюсь чтением литературы, статей на тему устройства ЯПов.

Например:

Что операторы это просто функции,
Литералы это сокращения названия объектов,
Обёрток примитивов в объекты,
ООП (прототипность и классикческое в самом языке под капотом),
Что такое ключевые слвоа под капотом, если не функции и тп,
Отличие выражений от инструкциий также именно внутри(аргмуенты и в целом), и в целом вещи, связанные с этими темами.

Comments

[Dmitrii]

Возможно, можно обратить внимание на документацию на компиляторы С, С++ и их исходники.

[Saboteur]

ООП (прототипность и классикческое в самом языке под капотом),

ООП это вообще парадигма. В каких-то языках его можно придумать, в других оно встроено в идеологию.
Но это не прототипность, это именно парадигма.

[Adamos]

Интересуюсь чтением литературы

Сказано: "это все равно, что хотеть быть инженером вместо того, чтобы хотеть что-то конструировать" (с).

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

Answer 1

[mayton2019]

Литералы это сокращения названия объектов

Впервые такое слышу. Возможно фраза вырвана из контекста.

Вот литералы. Текстовый
"Hello"
Вещественное число
3.14

Что такое ключевые слвоа

Это зарезервированные слова которые являются частью синтаксиса языка.
Например.

class, interface, override, trait, extends, case ....

Из них нельзя делать имена переменных и их нельзя использовать
в спорных контекстах когда неизвестно что имеется в виду (ключевое слово
или то что ты хотел объявить).

Говорить о них обобщенно нет смысла потому что в каждом языке - свои такие слова.
Бери конкретный язык и по нему смотри.

Отличие выражений от инструкциий

По выражению я тебя адресую вот в эту статью https://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%80%D...

Здесь очень хорошо описано. Насчет инструкции - непонятно. Опять-же ты получаеться полез
в терминологический спор без контекста. Так не бывает. Вот чтоб ты понял. Если собрались
математики и начинают что-то обсуждать то самое первое что они делают - это договариваются.
Какие у нас будут символы что обозначать. Комплексные числа? Кольца? Алгебры и т.п.
Потому что инструкция в ассемблере - это одно а в другом - вообще другое. И если я попробую
обсуждать инструкии без понимания где я нахожусь - я буду смешно выглять.

ООП - это самая злая и безпощадная тема которая морочит головы новичкам. И начинать изучать
ООП надо уже на 3 курсе когда вы уже прошли структурное, логическое и все прочее программирование.
Когда вы уже понимаете теорию алгоритмов - и знаете что такое указатель на функцию. Знаете
что такое типизация и каких видов она бывает.

ООП - это софистика и схоластика современного айти и не дай бох вам попасть на собеседование
с такой подготовкой как щас. Поэтому если вы просто хотите проникнуться с духом ООП - изучите его
реализацию в одном языке. Например в C#. На примерах с кошкой собакой и с волком. И этого будет достаточно.
Больше для бизнес-программирования от ООП не требуется.

Comments

[werwer]

Понял, просто была мечта в любом языке привязать всё к обхектам.
Операторы, как функции.
Литералы, как сокращения объектов и затем последующей обёртки над ними(как js-е)

[mayton2019]

werwer, не надо натягивать все на объекты. Просто правильно написанная программа гораздо ценне чем какая-то программа где ты тянул все на объекты. Как сову на глобус.

[werwer]

mayton2019, понял, ну просто встречается столько противоречий, как примитивы, не примитивы как js-е
null возращает объект
fucntion вообще

и так далее
так и сойти с ума подавно можно

[mayton2019]

werwer, js - это хороший старт для карьеры но плохой пример для ООП. Не бери JS в качестве образца для этого дела. Я уже тебе написал какой язык брать.

[Stalker_RED]

werwer, в js примитивы это примитивы.
Если вы пытаетесь вызвать какой-то метод у примтива, то просходит "магия" - движок вместо того, чтобы ругнуться, преобразует примитив в соответствующий объект и вызывает метод. А при попытке использовать объект как примитив сработает магический valueOf() и вы получите примитив.

А в случае с null это вообще баг typeof, так и оставленный навеки ради обратной совместимости.

[werwer]

mayton2019, ну просто получается прототипное наследование, в отличии от классического мх

[Василий Банников]

werwer,

Операторы, как функции.

Далеко не во всех языках операторы являются функциями.
Очень часто (например в Си), операторы - это просто операторы, как ключевые слова.

[mayton2019]

werwer, в некоторых языках есть усиленная дисциплина наследования. Например в Scala поддерживаются sealed classes. Это когда иерархия создается один раз и больше не расширяется. Например Weekday имеет семь наследников : Monday, Tuesday .... e.t.c. 7 штук. Это запрещает в производном коде расшинять дни недели. Это важно. Это часть дисциплины. И это еще один из способова выражения
мысли программиста.

Можешь ли ты на прототипировании выразить эту мысль?

[Станислав Макаров]

werwer Советую остыть по поводу ООП и максимы "всё - объект", это один из самых дурацких абсолютов, которые я только встречал.
Объекты - это про абстракцию и изоляцию, т.е. когда хочется контролировать, как обрабатываются конкретные данные, способ управления сложностью так сказать.
Лучше читайте про более базовые вещи, поизучайте типизацию например, поизучайте TypeScript в конце-концов. И да, теорию тоже нужно читать, Stalker_RED привёл отличные примеры, когда язык вас просто "обманул" - вы пытались опытным путём найти логику там, где её в принципе быть не может (typeof null - это тупо ошибка реализации, которую узаконили в качестве фичи языка лишь бы не ломать совместимость).

[mayton2019]

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

К сожалению его не поняли или не услышали и стали вводить абстракции (да ООП это
абстракции) везде где ни нужно. Я был свидетелем когда в 2000х было абсолютное царство
JavaBeans. Это безсмысленная бюрократическая технология которая любое начинание или
любую девелоперскую инициативу оболакивает в какие-то непонятные простыни описания
и вообще фетишизирует любой пустяк. От такого вы выгореть можно. Хорошо хоть сейчас
фаза бумагописательства прошла и стали смотреть в корень проблемы. Нужен Record - на тебе
рекорд. И никаких бинов. Фетишизаторы плавно перетекли в Spring и сейчас там живут
и придумывают себе новые игрушки.

Бизнес фетишизировал ООП потому что оно позволяло мыслить квадратно-гнездовым способом
и создать некую новую бюрократию без бумаг и печатей но с таким-же мощным внутренним Lingua
Latina где все синьоры помидоры плохо знают математику зато хорошо знают в каком порядке
инстанциируется бин.

Answer 2

[Сергей Горностаев]

Answer 3

[Saboteur]

В каждом языке детали отличаются.
Операторы не просто функции, это как бы понятно, ибо некоторые операторы это вообще только часть структуры, и функцией быть не может.

Что вы вообще спрашиваете? Какой смысл?
у вас надерганы термины из разных источников, и видимо из источников описывающих разные языки программирования, отсюда и каша.
Выберите конкретный язык и прочитайте про его терминологию. Потом про другой.
Прошло уже 100+ лет с начала программирования, появились новые сущности, которые не подпадают под старую классификацию.

Answer 4

[Владимир Коротенко]

Вот вам мнение
С С++ С# Java - создавались как языки для энтерпрайза и людей с опытом
JS PHP Perl Python - так получилось
Другие типа модные языки создавались либо потому что могли, либо уже сейчас они не интересны
ИМХО

Comments

[Stalker_RED]

А rust и go к какому списку относятся?

А является ли brainfuck языком, если у него вообще нет ни примитивов ни операторов?

[Владимир Коротенко]

Stalker_RED, к go ближайший аналог visualbasic

и это не преуменьшение его потенциала.
Rust - вроде как его пророчат как убийцу С++ но как помните таких убийц было много

[Василий Банников]

Владимир Коротенко,

Rust - вроде как его пророчат как убийцу С++ но как помните таких убийц было много

Но Rust очень близок к тому чтобы действительно таким быть.
Хотябы благодаря тому что даёт те же возможности, что и C++, но гораздо дешевле в плане когнитивной сложности и сложности поддержки (хоть и местами ценой некоторой вербозности)
Сейчас имею удовольствие переписывать на работе один сервис с C++ на Rust и каждый раз удивляюсь тому, на сколько сложным/неочевидным C++ является исключительно из-за своего дизайна.

[Владимир Коротенко]

Василий Банников,

Rust - вроде как его пророчат как убийцу С++ но как помните таких убийц было много

[Василий Банников]

Владимир Коротенко,

очень близок к тому чтобы действительно таким быть.

Понятное дело, что C++ с нами ещё очень на долго, тк во всём мире уже наверно счёт на миллиарды строк кода на C++ идёт и десятки (а может сотни?)тысяч разработчиков на нём

[mayton2019]

Василий Банников, по сути когда говорят о С++ обычно имеют в виду легаси. И о том как тяжело
стало искать молодых синьоров и синьорит.
И о том как это все поддерживать в будущем. И бизнес подсознательно начинает
искать замену в виде чего-то более простого в смысле найма людей. Из гугловых
проектов я помню Go-Lang и Carbon. Этот карбон еще не вылупился из гнезда
но в нем уже были заявлены приятные фичи такие как бинарная совместимость
с библиотеками С++. Я честно говоря пока не видел на нем проектов но видел
восторженных блоггеров.

Еще из убийц. Интересный был проект ZigLang. Хотя он вроде как был убивцей
не плюсов а обычных Сей. Но его автор в своем докаладе достаточно красиво
описал цели и задачи. Главное - улучшить то что было в Си но не более того.
Плюс он реализовал метапрограммирование на синтаксисе языка а не на макросах.
Это приятно. Мне он понравился но как всегда не хватило драйверов ко всему на свете.

Еще интересный и очень красивый язык Nim. Я на нем хотел написать себе утилитку
для блочного бекапа баз данных. Что-то типа RMAN но без Oracle а чтоб можно
было любую БД (Postgres) тоже бекапить и вести реестр бекапов. Бросил. В силу
своей нетерпеливости. Но думаю когда нибудь допишу. Не хватало каких-то пустяков.
Толи найти суммы MD5 толи еще чего-то. Этот Nim был еще куцый на библиотеки.

Еще был один убийца и душегуб плюсов. Назывался Digital Mars D. ИЛи Dlang.
Где он сейчас? Кто знает?

[Василий Банников]

mayton2019,

И о том как тяжело
стало искать молодых синьоров и синьорит.

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

Answer 5

[Дмитрий Кинаш]

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

Comments

[Владимир Коротенко]

сначала были пальцы - все считали на них
потом был абак - дошел до наших лет
после шестеренки - вау круто
после машинные коды - да кто тут может ошибется?
после асм - блин ну тут то все понятно?
С - тут же вообще понятно и работать будет везде
С++ - ну что поцанчики ловите по щщам от ООП
Ява - С++ отстой я еще и о памяти помогу забыть
JS - не ну а чо? Сказали написать за 5 дней на коленке? 1995 ой, 2000 ой, 2023 лучше бы меня мама не родила
PHP - ну собрал я из говна и палок что то для домашней страницы и что?
Pascal - давайте соберем поделку для обучения.
Python - Давайте соберем фигню для обучения
C# - так с явой у нас не срослось, давайте мы сделаем свой язык с пропертисами и разным сахаром, который уделает всех?
GO - так стоит задача сделать язык для тупых, что бы натаскать можно было за две недели и что бы не хуже чем C# и Java, платим 100500 баксов в секунду

[Дмитрий Кинаш]

До компьютеров никого не интересует, так как обсуждаем компьютерные языки программирования.

после машинные коды - да кто тут может ошибется?

Ошибались все и очень много. Редкая перфокарта писалась с первой попытки. Отладки практически не было (разве что амперметром на клемах проца, но к технике пускали только опытных инженеров). Чтобы снизить процент ошибок из-за человеческой невнимательности, и был придуман АСМ.

после асм - блин ну тут то все понятно?

Первые версии типа TASM были по сути теми же машинными кодами, но в более удобном виде. А вот MASM под MS-DOS уже был более похож на язык высокого уровня. Но проблемы дебага никуда не делись и для отладки нужно было исписать несколько тетрадок, фиксируя состояние регистров на каждом такте.

С - тут же вообще понятно и работать будет везде

Хрен там. Это процессоро-зависимый язык. Это у Java и намного позже возникла фишка "один раз написал, всюду запускай", а под С тебе нужны отдельные версии кода (до компиляции еще дойти нужно) под каждые ОС разрядность и тип проца. Программисты страдают и этот язык сейчас популярен только для embedded систем. По сути не сильно далеко ушел от АСМа, но на С и Pascal стало приятно писать благодаря появившимся IDE от Borland - большая половина ошибок теперь не доходила даже до компиляции (и прятный дебагинг).

С++ - ну что поцанчики ловите по щщам от ООП

Настоящим ООП был Smalltalk от Xerox. С++ вместе с Objective-C появились значительно позже и были по сути лишь ООП-надстройками над классическим С (с сохранением всей низкоуровневой магии)

Дальше даже не буду смотреть - маленький кусочек императивщины и ООП под неправильным углом. Ни слова про логические языки, функциональные, скриптовые, декларативные, доменные (DSL), языки управления данными (не только SQL) и прочие узкоспециализированные типа Q# для квантовых вычислений.

[Владимир Коротенко]

Дмитрий Кинаш, можете дополнить, но думаю вы поняли мою иронию.
Кстати мое мнение хорошо что сейчас зашла ардуина и стм. Меньше мусора ближе к корням и пониманию как все работает

Answer 6

[Steel_Balls]

в Книге Дракона всё это есть.
Стыдно не знать классику

Answer 7

[Станислав Макаров]

Все советуют вам Книгу Дракона. Книга, безусловно, отличная и классическая, но я что-то по вашему вопросу сомневаюсь, что вам нужно именно это - реализация и механика/синтаксис языков. Попробуйте Programming Language Pragmatics - мне кажется там ответы на ваши вопросы.