IT в России и мире в реалиях мирового кризиса

Цитата: adolfus от 12.11.2024 22:35:05Литограф  ASML -- это всего лишь инструмент. Очень сложный, но все таки инструмент. Тут все ясно -- нет инструмента, нет и изделия. Но, ASML свои литорафы может продать куда угодно кроме TMSC. Если не сегодня, то завтра. И что этому инструменту подсунут в виде фотошаблонов, то он в кремнии и выдаст. А вот сделать фотошаблоны. чтобы выхлоп литографа  ASML функционировал как задумано, это уже и есть та самая технология. Вот ее TMSC и закокомил.

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

Цитата: Vaal от 13.11.2024 11:24:53А фотошаблоны, - это оснастка для литографа. Значительно менее сложная, чем литограф.
Ежели недокитайцы пожелают закрыть фотошаблоны, ASML вполне может закрыть литографы для них. Эта история только начинается, короче.

Что начит "закрыть"?
 
Это их собственная внутренняя "фишка", они её, в отличии от продукции ASML не экспортировали. И "на сторону" не продавали.
 
Т.е. необходимое, чтобы на входе изображение которое должно получиться после травления экспонированной пластины превратить на выходе в маску для фотошаблона с учётом дифракции. Решение обратной задачи с нелинейными формами. Со всеми необходимыми для рассчёта совсем не слабыми вычислительными мощностями.
 
И плюс всё то, о чём написал Senya выше:

Цитата: Senya от 13.11.2024 11:31:23А дальше идут десятки (сейчас может уже и сотни, я от жизни отстал) таких операций как ионная имплантация всевозможными легандами, окисление, напыление, травление ионное и химическое, и отжиги, отжиги, отжиги для восстановления кристаллической структуры после каждого чиха, и всё это с точностью до вольт, градусов и секунд, чтобы в процессе не уничтожить уже созданные на кристалле структуры. Что собственно и есть технология (а всё предыдущее - производственная оснастка). Ну и библиотеки элементов, где все пространственные структуры на кристалле спроектированы так, чтобы их можно было с помощью данной технологии изготовить. Сложное это дело.

 
Причём даже при размещении завода в США... они по-прежнему все рассчёты могут делать у себя на Тайване. Файл со слоем туда, файл с экспозицией фоторезиста для изготовления шаблона обратно.

Цитата: adolfus от 13.11.2024 09:43:43Фотошаблон производится из файла с описанием топологии изделия.
Степпер берет шаблон, оптически его уменьшает и "тиражирует" по пластине, сдвигая ее на определенный шаг и засвечивая. Это один из компонент того "сарая", что производит ASML.
И тут вопрос -- каким образом излучение УФ лазера с длиной волны ~100 нм, проходя через маску, создает на кристалле картинку с разрешением несколько нм. Дело в том, что реально на кристалле после прохождения маски из-за диффракции на всей маске создается определенная интерференционная картинка. Т.е. вся маска вносит вклад в каждую точку результирующей засветки, которая представляете собой интерференционную картинку. И создание фотошаблона -- это создание таких масок, проходя через которую картинка на кристалле будет представлять собой требуемую топологию. Достаточно сложная вычислительная задача и не только лишь все... TMSC из тех, кто умеет и ASML к этому никакого отношения.

Какой нах УФ лазер 100нм?
Передовые сканеры работают уже на рентгеновсом излучении. Рентгеновскую оптику, кстати, для ASML русские разработали... а делают немцы, если не ошибаюсь. Там длина волны порядка 10 нм.

Сейчас в РФ ваяют собственные сканеры. К 2030 обещают достижение сравнимых параметров.С оригинальным источником рентгеновского излучения, и собственной системой рентгеновской оптики.
Собака лает, - караван идет.
Ну, дай то бог...

Цитата: Pnb от 13.11.2024 09:12:06У нас пользовались в интерфейсах только чисто виртуальными функциями. Тогда в структуре первым элементом идет адрес таблицы с адресами функций. Конечно все равно могут быть разночтения типа 32\64 или соглашения о вызове функций. Во всяком случае так можно было взаимодействовать между борландом и микрософтом.

Вызывать методы класса из борланда в майкросорт
Вы очень смелые люди. Уважаю

Цитата: ivrom от 08.11.2024 20:39:51Большинство считают С++ слишком сложным в первую очередь для понимания. Это непонимание, как писать на нём просто и безопасно. А раз так, то похоже он будет вытеснен в область системного программирования [только]. И мир продолжит экстенсивный путь развития в виде увеличения размера памяти и количества ядер процессора для покрытия издержек "непонимания". Так тоже делать можно. Только это печально. Да здравствует Питон!

   
Если для программиста С++ оказался "сложным", то такой программист способен писать только какие-то диалог-боксы для какой-то одноразовой примитивной системы...
Это какой-то индийский погромист...

Цитата: ivrom от 08.11.2024 20:39:51Большинство считают С++ слишком сложным в первую очередь для понимания. Это непонимание, как писать на нём просто и безопасно.

Безопасность в С++ достигается полным отказом от наследования, полиморфизма и прочего зла, типа создания шаблонов, котороыми никто кроме меня не будет пользоваться.
Также, если вы не пишете oбработчики исключений, позволяющие исправить ситуацию, вызвашую исключение, и продолжать выполнение программы, то нет необходимости использовать try-catch.
И самая мякотка -- повторное использование классов. Когда я начинал программировать на С++, мои классы изобиловали не нужными на тот момент вещами -- я верил, когда-нибудь это может понадобиться. Спустя какое-то время выяснилось, что ничего из того, что было "про запас" написано, так и не сыграло. При этом классы в разных проектах, выросшие из таких "избыточных", постоянно дорабатывались под конкретную задачу и в результате между ними осталось мало общего. Сегодня я вообще не думаю насчет того, что разрабатываемый класс может понадобиться в каком-нибудь другом проекте -- я в это не верю. Время, потраченное на проектирование "прозапас" и прочую шлифовку -- это просто просранное время.

Цитата: adolfus от 14.11.2024 01:01:33Безопасность в С++ достигается полным отказом от наследования, полиморфизма и прочего зла, типа создания шаблонов, котороыми никто кроме меня не будет пользоваться.

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

Цитата: adolfus от 14.11.2024 01:01:33
Также, если вы не пишете oбработчики исключений, позволяющие исправить ситуацию, вызвашую исключение, и продолжать выполнение программы, то нет необходимости использовать try-catch.
И самая мякотка -- повторное использование классов. Когда я начинал программировать на С++, мои классы изобиловали не нужными на тот момент вещами -- я верил, когда-нибудь это может понадобиться. Спустя какое-то время выяснилось, что ничего из того, что было "про запас" написано, так и не сыграло. При этом классы в разных проектах, выросшие из таких "избыточных", постоянно дорабатывались под конкретную задачу и в результате между ними осталось мало общего. Сегодня я вообще не думаю насчет того, что разрабатываемый класс может понадобиться в каком-нибудь другом проекте -- я в это не верю. Время, потраченное на проектирование "прозапас" и прочую шлифовку -- это просто просранное время.

Все эти претензии могут быть высказаны к любому объектно ориентированному языку. Ничего С++ специфического здесь не озвучено.

Давайте пойдём от обратного. Рассмотрим, кто и на чём программирует. По большому счёту, языки делятся на транслируемые (компилируемые) и интерпретируемые. Есть множество ресурсов с указанием некоего рейтинга (по использованию?) языков программирования. На вершине находятся сплошь интерпретируемые языки, такие как Python, JavaScript (в обоих ипостасях - как клиентский язык и как Node.js), Java, PHP. Наличие jit опустим - он может наличествовать в любом интерпретируемом языке. Всё это массовый сегмент для большинства программистов, имеющий низкий порог вхождения с точки зрения образования и опыта.

С другой стороны, в наличии языки программирования для написания высокопроизводительных (как правило серверных) приложений и ОС, GUI. И в этом сегменте наличествует С, С++. Есть некоторое количество golang(самое известное - Docker, зачем писали на go - не знаю). Rust и странно-для-чего-деланный C# (для Windows, про Mono помнить можно, но лучше забыть) в некоторых количествах присутствует.

Итак, вам нужно написать высокопроизводительное сетевое приложение/демон. Каков будет ваш выбор? Интерпретируемые языки отпадут сразу и по производительности и по потребляемым ресурсам. Не боясь особо ошибиться, это будет C. С++ воспоследует. Если для демона важны расширения посредством разделяемых библиотек - то это 99% будет С. Иначе - возможны варианты. Но стоит заметить, что именно относительно свежие дополнения С++ в виде поддержки асинхронных алгоритмом + корутины сделает процесс написания максимально безболезненным и быстрым. И что самое важное - логика программы будет прямой, почти как в отсутствие конкурентной среды и с блокируемыми системными вызовами. И исключения будут работать и обрабатываться правильно.

А вот в языках, где event loop  работает с событиями (через futures/queues + обработчик события, например в виде .then{...}) логика рваная и инвертированная. В такой среде исключения не работают правильно. Скажем, libevent и Node.js именно так и построен. Вы озвучили проблемы с исключениями в С++ в такой среде, но именно для С++ и асинхронных алгоритмов с корутинами это ни разу не проблема.

В общем, если вам что-то не нравится, это не означает, что есть в наличии то, что нравится. В таком случае используют то, что максимально удовлетворяет запросам. От этого обычно и пляшут. И С++ остаётся пока №1 среди транслируемых (компилируемых) языков программирования. Но у С есть сегменты, где он превалирует. Впрочем, писать на С++, как на С, тоже никто не мешает, получая бенефиты от более строгой типизации (значит - меньше ошибок) и большей скорости от встраивания, где это нужно (и от уменьшения косвенной адресации в общем). 

А где требования пониже и/или ресурсы (программистские) пожиже - там и Python с Node.js свою нишу найдёт.

PS Существуют книги/учебники из цикла "XXX за YYY дней". Применительно к С++ это "С++ за 21 день". Я его ради любопытства лет 20 назад поглядел. Так это вполне себе был учебник, чтобы за месяц начать что-то писать на С++. Так что и для новичков С++ не имеет запредельной сложности для вхождения.

PPS Утверждаю, что основные претензии к С++ базируются на очень старых версиях языка (или на вовсе нестандартном Microsoft VS), по крайней мере не позже С++98. С каждым новым стандартом С++ становится проще для использования. Да, дополнительные ключевые слова, алгоритмы и классы вводятся, но разумным будет забывание и исключение устаревшего и адаптация нового. Количество используемого и необходимого для запоминания материала может даже уменьшится.