ramntry

Я поддержу JS и Python.

Первый, потому что благодаря node.js он позволяет программировать и фронтент, и бекенд - одним языком вы убьёте двух зайцев, быстрее сможете начать что-то делать для своего проекта. Возможно, даже трёх зайцев, так как некоторые NoSQL базы данных используют подмножество JS в качестве языка запросов, а NoSQL-подход в изучении попроще классического реляционного (в конце концов, вы автоматически получите представление о JSON, которому в большинстве случаев удаётся эффективно замещать значительно более тяжёлый XML).

Второй, потому что он прост и очень много умеет, как в веб, так и в области автоматизации системного администрирования. Значит, в процессе его изучения вы сможете применять получаемые знания на практике, прямо на рабочем месте. Python вам подарит Django, который до поры до времени вообще скроет от вас премудрости работы с базами данных (благодаря ORM). Проще он потому, что имеет простую объектную модель, предлагает большой набор встроенных структур данных с хорошо продуманными интерфейсами (туториал на офф.сайте сразу вам скажет, что dict - ассоциативный массив, подробно расскажет, как им пользоваться. В JS можно умом двинуться, пока поймёшь, что Object и есть ассоциативный массив и как его в таком качестве эксплуатировать).

Но JS для фронтенда всё равно придётся выучить.

Ruby не стану советовать. Для вас Ruby в связке с Ruby on Rails будет тем же тандемом Python + Django, только 1) ощутимо более сложным для изучения 2) практически неприменимым на основном месте работы 3) перегруженным в смысле конкуренции на рынке труда не хуже PHP.

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

А ещё есть такое предложение: может быть, вам лучше оглядеться на работе по сторонам, найти веб-разработчика в своей компании и по душам перетереть этот вопрос с ним? Так вы и больше узнаете, и источник ваш будет иметь надёжность, вам понятную (в отличие от анонимных товарищей из сети), и, в идеале, получите наставника.

Выяснилась некоторая деталь: в первую очередь в искомом языке интересна работоспособность Y-комбинатора, поскольку он позволяет решать рекурсивные уравнения, что, в свою очередь, позволяет создавать рекурсивные функции. Однако, не смотря на формальное равенство (конвертируемость) ∀ X ( λ ⊢ Y X =_β X (Y X) ), ни Y X не β-редуцируем к X (Y X), ни наоборот. Существует, однако, лучший в этом смысле и аналогичным по своим практическим возможностям Θ-комбинатор, придуманый Аланом Тьюрингом, а также множество других комбинаторов фиксированной точки (по ссылке также можно найти множество примеров реализации комбинаторов на различных языках, что крайне ценно). Их вычислимость, тем не менее, по-прежнему чувствительна к порядку редукции, но требование нормального порядка избыточно. Существуют помимо понятия нормальной формы терма, понятия головной (или заголовочной) нормальной формы, слабой головной нормальной формы, которые используются в некоторых языках даже с принципиально аппликативным порядком редукции и приводят к тому, что терм-аргумент, едва став λ-абстракцией (в слабом случае), перестает вычисляться и передается в тело функции (сокращается крайний левый внешний редекс, как при нормальном порядке). Это делает возможными в таких языках специальные трюки, которые за счет некоторой модификации канонических комбинаторов (навешивания на них «лишних» λ-абстракторов) добиться нужного порядка вычисления.

О! Нашлась такая вещь: LCI Очень неплохо для начала.

Посмотрите как минимум главу www.plantation-productions.com/Webster/www.artofasm.com/Linux/HTML/Volume2.html из
Art of Assembly Book — более компетентного и доходчивого введения в вопросы архитектуры ПК с позиции программиста я
не встречал. Также можно посоветовать выборочные главы из Брюса Эккеля — его двух книг по C++:
«Философия С++. Введение в стандартный С++» и
«Философия C++. Практическое программирование».
В этих книгах, где это возможно, Б. Эккель особенно подробно останавливается на некоторых вопросах работы с памятью.
Например, детально описывает процесс передачи по значению больших структур в функции — полезная информация, если
вы хотите представлять, как вы программируете стек, когда работаете на C++.

«а на ноутбуке установлен такой же как VGA как в ноуте» — я вас положительно не понимаю. На ноутбуке как в ноуте (папа). Кстати да, папа. И на десктопе тоже папа. Если я возьму переходник с VGA мамой, мне еще и кабель DVI-I брать придется — а так у меня уже есть кабель VGA папа-папа. Мы с вами папу с мамой не путаем? :) По мне папа — это с пинами который.

Хорошо, спасибо. Вы не подскажете, где посмотреть, как делается правильно? В литературе удается найти только абстрактные простые примеры, к сожалению. Комбинаций организации сервера (процессы/потоки, они же — по одному на клиента или по числу ядер, пул потоков, select/pol, epoll, они же — руками или с помощью asio, poco и т.д. и т.п.) безумного много.