История изменений

Нет такого понятия как «настоящий язык программирования». Динамическая типизация не является препятствием для создания достаточно сложных программных продуктов.

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

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

Посмотри/нагугли бенчмарки жавы мы node.js. Как правило, они идут ноздря в ноздрю, и по производительности, и по потреблению памяти. Как так, ведь одно — православная статика, а второе — б-гмерзкая динамическая скриптовуха? Далее, как ты думаешь, почему жавоприложения почти никогда не падают с сегфолтом/выполнением стэка? Может быть потому, что:

1. Производительность определяется не динамической/статической типизацией, хотя большая производительность коррелирует со статической;
2. Надежность определяется не динамичностью/статичностью типизации.

Так удобно сидеть на пеньке и говорить «во всем виноваты евреи», но совсем другое настроение возникает, когда ты, как я, пытаешься реально изменить положение, и внезапно выясняешь, что все эти люди на пеньках могут говорить что угодно, поскольку за слова свои никак не отвечают, за словами нет действий.

Вот расскажи мне, например, насколько статичны целочисленные типы в C/C++? Это те, которые превращаются друг в друга неявно, теряют/получают знак, и тихо переполняются. Потому я говорю, что для надежности программы нужна проверка корректности применения-интерпретации данных, а не какой-то там мутный «тип». Прототип функции является подсказкой для компилятора, позволяющей заметить наиболее очевидные ошибки передачи данных — это особо хорошо видно на примере Си, в котором никаких прототипов у функций изначально вообще не было. Но эта подсказка не выполняет и половины работы по проверке корректности.

Далее, по производительности. Я уже не буду мучить вас плавными подходами: скажу сразу правильный ответ: в тормознутости кода Java/C#/C++ виноваты виртуальные функции и объекты размером по 1-4 байта, которые вместо плотных проходов всяким SIMD-ом (или даже классическим маш кодом) без прыганий по адресам вирт методов и бесконечных cache miss-ов по всей куче дают что дают. Даже в середине 90-х Java уже медленно бегала, из-за чего создали HotSpot.

Кагбэ при чем тут динамическая типизация? Можно сделать тэг и статичные функции, которые займут минимум места в памяти (снижение cache miss) и не будут требовать косвенных вызовов функций. Но вроде как по прежнему динамические типы же ж. В C++ есть std::variant, в Object Pascal есть Variant.

Другое дело, что проблемы конкретной скриптовухи с производительностью, как, например, CPython (но при этом НЕ JavaScript) связаны с устройством языка и стандартной библиотеки, которые не связаны с динамической типизацией. Например, в JS есть возможность явно вызвать какое-нибудь Array.prototype.map(val) — все современные интерпретаторы JS превратят это не в цепочку запросов к ассоциативному массиву по ключам «Array», «prototype», «map» (как это делает питон, между прочим), а к прямому доступу к функции «map». Далее уже через алгоритмы оптимизации V8 массивы могут из массива ссылок на объекты стать, например, сплошным массивом чисел int32.

Между прочим, оба упомянутых инструмента уже есть в Haskell, а именно, автоматически тэгированные данные и вручную объявленные unboxed ячейки. И уже не совсем ясно, кем является хаскель в твоей черно-белой дихотомии.

Изучение программирования как раз и нужно чтобы закрепить и углубить основы информатики - двоичную систему, работу АЛУ и так далее. Учить информатике без основ теории — всё равно что строить дом без фундамента

Ты бы еще предложил выдавать права на вождение только после экзамена на термодинамику ДВС. Я двоичную и аналоговую логику сам проектировал в свое время, но спустя годы у меня не возникало идеи «ах, как мне пригодилось знание принципов проектирования процессоров при написании кода отправки JSON формочки».

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

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

Опять же, в первом языке это не нужно. Ученику вначале нужно понять как делается то или другое действие. Что, например, перевод строки ‘1234’ в число 1234 — это нетривиальная операция, требующая определенный код. Чужие библиотеки стоит использовать только после того как написал хотя бы пару-тройку своих

Я в упор не понимаю это вашей риторики про обучения программированиям ребенков. Это как если бы я говорил про обучение детей сексу или играм в доту. Ладно, курсы оператора стиральной машинки и ПДУ телевизора. Блин, да я кодингу учился по книжкам 80-х годов про фортран и бейсик НА БУМАЖКЕ, а потом, как комп появился, воротил нос от виндовой консоли и мечтал писать скрипты на баше. Тот же кобол был создан бабушкой для бабушек — до сих пор бабушки на нем пишут и не жалуются. Реально серьезно учиться нужно для получения продвинутых навыков, которые порой не могут освоить даже мартышки с годами опыта.

Потому я бы сказал, что есть только одна проблема: отдельные конкретные ЯП имеют порог входа неоправдано выше, чем то требуется. Например, C/C++/Rust или Haskell.

Нет такого понятия как «настоящий язык программирования». Динамическая типизация не является препятствием для создания достаточно сложных программных продуктов.

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

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

Посмотри/нагугли бенчмарки жавы мы node.js. Как правило, они идут ноздря в ноздрю, и по производительности, и по потреблению памяти. Как так, ведь одно — православная статика, а второе — б-гмерзкая динамическая скриптовуха? Далее, как ты думаешь, почему жавоприложения почти никогда не падают с сегфолтом/выполнением стэка? Может быть потому, что:

1. Производительность определяется не динамической/статической типизацией, хотя большая производительность коррелирует со статической; 2. Надежность определяется не динамичностью/статичностью типизации.

Так удобно сидеть на пеньке и говорить «во всем виноваты евреи», но совсем другое настроение возникает, когда ты, как я, пытаешься реально изменить положение, и внезапно выясняешь, что все эти люди на пеньках могут говорить что угодно, поскольку за слова свои никак не отвечают, за словами нет действий.

Вот расскажи мне, например, насколько статичны целочисленные типы в C/C++? Это те, которые превращаются друг в друга неявно, теряют/получают знак, и тихо переполняются. Потому я говорю, что для надежности программы нужна проверка корректности применения-интерпретации данных, а не какой-то там мутный «тип». Прототип функции является подсказкой для компилятора, позволяющей заметить наиболее очевидные ошибки передачи данных — это особо хорошо видно на примере Си, в котором никаких прототипов у функций изначально вообще не было. Но эта подсказка не выполняет и половины работы по проверке корректности.

Далее, по производительности. Я уже не буду мучить вас плавными подходами: скажу сразу правильный ответ: в тормознутости кода Java/C#/C++ виноваты виртуальные функции и объекты размером по 1-4 байта, которые вместо плотных проходов всяким SIMD-ом (или даже классическим маш кодом) без прыганий по адресам вирт методов и бесконечных cache miss-ов по всей куче дают что дают. Даже в середине 90-х Java уже медленно бегала, из-за чего создали HotSpot.

Кагбэ при чем тут динамическая типизация? Можно сделать тэг и статичные функции, которые займут минимум места в памяти (снижение cache miss) и не будут требовать косвенных вызовов функций. Но вроде как по прежнему динамические типы же ж. В C++ есть std::variant, в Object Pascal есть Variant.

Другое дело, что проблемы конкретной скриптовухи с производительностью, как, например, CPython (но при этом НЕ JavaScript) связаны с устройством языка и стандартной библиотеки, которые не связаны с динамической типизацией. Например, в JS есть возможность явно вызвать какое-нибудь Array.prototype.map(val) -- все современные интерпретаторы JS превратят это не в цепочку запросов к ассоциативному массиву по ключам "Array", "prototype", "map" (как это делает питон, между прочим), а к прямому доступу к функции "map". Далее уже через алгоритмы оптимизации V8 массивы могут из массива ссылок на объекты стать, например, сплошным массивом чисел int32.

Между прочим, оба упомянутых инструмента уже есть в Haskell, а именно, автоматически тэгированные данные и вручную объявленные unboxed ячейки. И уже не совсем ясно, кем является хаскель в твоей черно-белой дихотомии.