Comments 143
я подсел на Научно-технический рэп )
Ну тогда уж вот ещё: https://youtu.be/1S1fISh-pag
С — крутой язык, сложно представить какой ЯП сможет его заменить.
Чуть личной истории
Помнится, лет десять назад, программировали на С используя Borland С++, славные были времена.
Сейчас что не более-менее новый язык — так сразу плагины для него к многим IDE и т.п., автодополнения строк\функций и т.п…
… у нас в универе были контрольные работы по программированию: дают аркуш А4, и сиди пиши программу ) потом бумажку на проверку преподу и можешь переносить свой код в ПК и компилировать.
с одной стороны — бред, но с другой: функции, инструкции языка и т.п. прочно сидят в голове, а с этими автокомлитами человеку через год-другой сложно будет вспомнить с десяток самых нужных функций…
С давних времен — привычка похожая осталось, когда на серваке быстро чтото сделать\проверить — открывается nano, и пишешь) полезная практика.
Сейчас что не более-менее новый язык — так сразу плагины для него к многим IDE и т.п., автодополнения строк\функций и т.п…
… у нас в универе были контрольные работы по программированию: дают аркуш А4, и сиди пиши программу ) потом бумажку на проверку преподу и можешь переносить свой код в ПК и компилировать.
с одной стороны — бред, но с другой: функции, инструкции языка и т.п. прочно сидят в голове, а с этими автокомлитами человеку через год-другой сложно будет вспомнить с десяток самых нужных функций…
С давних времен — привычка похожая осталось, когда на серваке быстро чтото сделать\проверить — открывается nano, и пишешь) полезная практика.
UFO just landed and posted this here
ИМХО только С++.
После С++ голый С кажется языком, подходящим только для отстреливания себе ног.
После С++ голый С кажется языком, подходящим только для отстреливания себе ног.
ИМХО только Rust.
После Rust голый C++ кажется языком, подходящим только для отстреливания себе ног.
Не подвергайте себя и других опасности, используя небезопасные языки. Ваш код может и убить кого-нибудь.
После Rust голый C++ кажется языком, подходящим только для отстреливания себе ног.
Не подвергайте себя и других опасности, используя небезопасные языки. Ваш код может и убить кого-нибудь.
С++? О, да — замечательный язык!
…
myprint(a);
b = a;
myprint(b);
…
0x00143020
0x00285040
…
Я был в полном… «восторге»! Operation overload!
…
myprint(a);
b = a;
myprint(b);
…
0x00143020
0x00285040
…
Я был в полном… «восторге»! Operation overload!
Ничего не понял, кроме того, что С++, как и С — непростой инструмент, перед использованием нужно прочитать инструкцию.
Скажите, если не секрет — вам приходилось адаптировать под новую платформу некую, систему на C++ размером в двоичном коде от 10MB до 16MB кода и числом строчек исходного кода за 200000?
Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
Мне пришлось, и она тупо падала неизвестно где и откуда. Я потратил дня 3-4 прежде чем понял, что результат присвоения не гарантирован. Инструкцию к языку я конечно прочел годы назад. Но не был готов, что на C++ надо проверять каждый шаг и если упустил перезагрузку оператора в 200тыс строк кода для этого типа данных, то увы…
UFO just landed and posted this here
Я так понимаю, что Вам ближе языки где нет перегрузки функций/методов и запрещено не явное приведение типов? Но тогда причем тут C++, такой пример можно написать много на чем.
У нас есть класс для возвращаемых ошибок. Он может содержать одну ошибку. Иногда возникает необходимость вызова подряд нескольких функций, каждая может вернуть ошибку. Без перегрузки операторов пришлось бы иметь два объекта, в первый получать результат функции и если во втором нет ошибки приравнивать второй к первому.
С перегрузкой же это реализуется элементарно и перегрузив оператор |= вызываем функции подряд, а в конце получаем первую возникшую ошибку.
P.S. все ошибки фатальные, важно получить первую возникшую и не замаскировать ее успешным выполнением следующей функции.
Извините, но это несерьезный аргумент в пользу overloading. Он может работать на небольшой программе, но в случае комплексов на сотни тысяч строк кода поиск ошибок слишком дорого обходится.
Несерьезный аргумент — это ругать перегрузку, хотя на самом деле стоит ругать свою неопытность.
Присвоение объектов без попытки разобраться как это работает — вот это несерьезно!
Объект а мог выделять себе память и использовать её по указателю, когда вы присвоили объект a объекту b произошло копирование указателя, затем вы уничтожили объект a и его деструктор освободил память… что будет при попытке вызвать у объекта b функцию работающую со скопированным указателем???
Первые вопросы которые у вас должны были возникнуть "А что что это за объекты? А можно ли их копировать? А что происходит при копировании?". Но, по своей неопытности, вы этого не сделали. За что и получили столько минусов в карму. Впрочем, минусующие тоже хороши — им стоило бы вам сказать за что.
Есть проекты на кучу строк кода, на миллионы долларов и от которых зависят жизни людей(медицинское оборудование). А поиск ошибок неопытными работниками в любом случае обходится слишком дорого.
Присвоение объектов без попытки разобраться как это работает — вот это несерьезно!
Объект а мог выделять себе память и использовать её по указателю, когда вы присвоили объект a объекту b произошло копирование указателя, затем вы уничтожили объект a и его деструктор освободил память… что будет при попытке вызвать у объекта b функцию работающую со скопированным указателем???
Первые вопросы которые у вас должны были возникнуть "А что что это за объекты? А можно ли их копировать? А что происходит при копировании?". Но, по своей неопытности, вы этого не сделали. За что и получили столько минусов в карму. Впрочем, минусующие тоже хороши — им стоило бы вам сказать за что.
Есть проекты на кучу строк кода, на миллионы долларов и от которых зависят жизни людей(медицинское оборудование). А поиск ошибок неопытными работниками в любом случае обходится слишком дорого.
С++ кажется языком, подходящим для отстреливания чужих ног.
А Perl просто отстреливает всех, кто пытается прочесть исходники.
А Perl просто отстреливает всех, кто пытается прочесть исходники.
Вы сильно ошибаетесь, в плюсах не меньше способов отстрелить себе ногу, а может даже больше, учитывая, что он сильно сложнее голого си…
Embarcadero Rad Studio (C++Bulder) — по прежнему — один из лучших инструментов для написания C кода :)
И это хорошо! Потому что я знаю, что могу в Си запросто отстрелить себе ногу 1000 способами. Свобода! А вот в явах всяких и прочих похапе попробуй-ка? Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.
Шаг в сторону — и… и ничего. Скукота и тошнота, прям как бейсик.
Я попрошу не оскорблять Бейсик! В нем тоже есть возможность стрелять по ногам — POKE, например.
Переходите на плотное использование JNI в Java и жизнь станет немного ярче.
Попробовал на Rust сделать 1 << 65, а он мне не дал. Я сел и заплакал: как же без этого? Или целочисленное переполнение… Куча милых фич недоступна. В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.
А что вы имели ввиду под 1 << 65? Что оно вообще должно делать? При компиляции результат не влезает в 64 бита, о чём компилятор и говорит.
Или целочисленное переполнение…
Там оно есть. Просто по умолчанию считается, что эта фигня не должна происходить и debug-сборка паникует на этом. release-сборка паниковать не будет.
Если же нам требуется переполнение, как часть того, чего мы хотим достичь, то есть удобные варианты сказать "здесь должно быть переполнение". Все эти checked_, saturating_, wrapping_, overflowing_ версии позволяют задокументировать сей процесс. https://doc.rust-lang.org/std/primitive.i64.html (для остальных типов тоже самое). Плюс тип std::num::Wrapping.
Куча милых фич недоступна.
В Сях выстрел в ногу ценен и сам по себе, и удовольствием, когда ногу успел отдёрнуть.
Всё там есть. Нужны UB? Есть их там. Так что спортивная стрельба по ногам тоже присутствует. Можно ставить у всего unsafe и радоваться. К вашим услугам нестабильная функциональность. Там тоже изредка можно в биатлон поиграть. В том числе и с компилятором.
Или вам не нравится, что подобное можно найти в коде простым grep? Хочется творить какую-то магию, которая by design нечитаема? Тогда да, rust не для вас.
Интересно, что в рамках этой метафоры можно сделать с ногами, например, в Хаскеле…
Джава поможет отстрелить — используйте JNI
(покашливает) Как насчет С99?
А почему не спрашиваете о С11?
Как говорил один мой преподаватель в университете(в который мы пришли после колледжа) "В колледже учат КАК сделать, а в университете учат КАКУЮ КНИГУ взять с полки, что бы прочитать как сделать".
Помнить наизусть все библиотечные функции языка — далеко не главное в программировании.
Тоже на первых курсах предпочитал писать код в Far Manager, без подсветки и автокомплита, воспринимая это как тренировку памяти и доказательство превосходства над одногруппниками. Разумеется, как только дело дошло до более-менее серьезных проектов, детская бравада закончилась.
Во-первых, автокомплит экономит огромное количество времени. Это особенно заметно на примере Javascript, где даже лучшие среды разработки предоставляют его постольку-поскольку.
Во-вторых, память в голове не бесконечна. Лучше потратить ее на что-то важное, а тонкости API оставить компьютеру.
В-третьих, может и вообще не нужно запоминать функции на случай, если они понадобятся только через год. Что это за ситуация, в которой не будет ни того же автокомплита, ни интернета, но необходимо срочно что-то написать?
Во-первых, автокомплит экономит огромное количество времени. Это особенно заметно на примере Javascript, где даже лучшие среды разработки предоставляют его постольку-поскольку.
Во-вторых, память в голове не бесконечна. Лучше потратить ее на что-то важное, а тонкости API оставить компьютеру.
В-третьих, может и вообще не нужно запоминать функции на случай, если они понадобятся только через год. Что это за ситуация, в которой не будет ни того же автокомплита, ни интернета, но необходимо срочно что-то написать?
Что, кроме нежелание учить что-то новое и унаследованный код, мешает заменить C и C++ на Rust или Ivory?
Надеюсь раст будет готов заменить этот «отличный язык». А то он такой замечательный, но только написать на нем код без уязвимостей практически невозможно, по крайней мере еще никому не удалось это сделать (в большом проекте)
Раст настолько крут, что сам фиксит любые баги за программистом?
Был бы «талант», а написать уязвимости можно на любом языке. :) Программист никогда не сможет до конца предвидеть как будет использоваться его продукт, для чего и как его будет применять пользователь. А программист это обычный пользователь со своими потребностями и желаниями, когда речь заходит о компиляторе. Раньше попадались байки, как «баги» компилятора использовались «во благо», а на пустом месте байки редко рождаются. :)
Очень сомнительно, что это произойдёт в ближайшие 10 (если не больше) лет. Даже если это случится, Rust займёт какую то полку, в лучшем случае вытеснит от туда какой нибудь язык (или просто слегка подвинет) и всё на этом закончится. Си ему не заменить.
Си ему не заменить.
Какие-нибудь аргументы будут? Ну кроме «на нем столько всего написано». Как показывает опыт какого-нибудь COBOL'а, это не карт-бланш.
Чтобы заменить С, нужен язык с малой стандартной библиотекой + компилятор, который за короткое время пробежит 40 лет эволюции для достижения лучшей скорости и / или меньшего размера бинарника.
Как вы сами оцениваете вероятность появления такого языка общего назначения и чудо-компилятора под него?
Как вы сами оцениваете вероятность появления такого языка общего назначения и чудо-компилятора под него?
Скоростью и размером бинарника занимается LLVM. Ему почему-то не понадобилось 40 лет, чтобы догнать GCC. Или вы про какой-то другой компилятор говорили?
Не будем забывать, что llvm начался в 2000 году, 18 лет назад. Кроме того, llvm является бэк-эндом, который работает не с синтаксисом языка напрямую, а с ассемблером виртуальной risc машины. При создании нового языка нужно ещё написать фронт-энд для него, что тоже небыстро и недешёво (индустрия любит стандарты, а комитеты быстро ничего не решают).
Кроме того, в новом языке нужно заинтересовать производителей железа, потому что именно они являются основными contributor'ами таких проектов, как gcc.
Наконец, по данным Phoronix, в конце 2017 года связка clang + llvm всё-таки немного отставала от gcc по производительности.
Кроме того, в новом языке нужно заинтересовать производителей железа, потому что именно они являются основными contributor'ами таких проектов, как gcc.
Наконец, по данным Phoronix, в конце 2017 года связка clang + llvm всё-таки немного отставала от gcc по производительности.
Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.
Еще есть проблема со стандартной библиотекой. Насколько я смог понять, там большие проблемы с модульностью. Если в С, например, я пишу под микроконтроллер, я могу использовать урезанную стандартную библиотеку без тредов хэш-мапов и всего такого, и все еще иметь возможность вызывать printf или memcpy. Даже нажористую плюсовую библиотеку, кажется (см. Christopher Kormanyos «Real-time C++») можно использовать на системах без динамической памяти подсовывая кастомные аллокаторы.
Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.
Еще есть проблема со стандартной библиотекой. Насколько я смог понять, там большие проблемы с модульностью. Если в С, например, я пишу под микроконтроллер, я могу использовать урезанную стандартную библиотеку без тредов хэш-мапов и всего такого, и все еще иметь возможность вызывать printf или memcpy. Даже нажористую плюсовую библиотеку, кажется (см. Christopher Kormanyos «Real-time C++») можно использовать на системах без динамической памяти подсовывая кастомные аллокаторы.
Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.
Например огромный недостаток по сравнению с C — отсутствие стандарта. Пока что стандарта языка не только нет, он даже не планируется: постоянно подкачивать новые фичи языка с гитхаба — это модно, молодежно, динамично, но не годится для индустрии.
По-моему ничем не отличается от переизобретения в каждой компании своего си-подобного языка при помощи макросов. Точнее, отличается, но в лучшую сторону
Растовая библиотека же работает по принципу «все или ничего». Или ты ограничен функциональностью core или же будь добр портируй std целиком: с динамической памятью, тредами и прочими радостями.
Кто вас так жестоко обманул?
Прошу прощения, перечитал еще раз. Да, много чего завязано на std, но вообще в планах это починить: internals.rust-lang.org/t/refactoring-std-for-ultimate-portability/4301. Подключаем отдельные крейты и готово.
Microsoft распилил дотнет на кучу мелких пакетов, сотни, возможно тысячи, сделать то же в расте ничего особо не мешает, если будет желание.
Microsoft распилил дотнет на кучу мелких пакетов, сотни, возможно тысячи, сделать то же в расте ничего особо не мешает, если будет желание.
Про «ultimate portability» — интересно, спасибо. Надеюсь, у них получится.
Аналогии с макросами я не понял, честно говоря. Я вот о чем: для C сейчас существует множество компиляторов. С открытым кодом, с закрытым кодом, оптимизированные под конкретный процессор, со встроенным theorem-prover'ом, компилирующие в прошивку для FPGA и т.д. — полный зоопарк под любую бизнес-модель и область применения.
Все это стало возможным благодаря тому, что язык С стандартизирован, любой может взять стандарт и написать под него компилятор. С Rust же это невозможно в принципе, просто потому что стандарта нет и не планируется. По сути Rust = rustc, и это достаточно серьезное ограничение для языка, который хочет захватить мир.
Аналогии с макросами я не понял, честно говоря. Я вот о чем: для C сейчас существует множество компиляторов. С открытым кодом, с закрытым кодом, оптимизированные под конкретный процессор, со встроенным theorem-prover'ом, компилирующие в прошивку для FPGA и т.д. — полный зоопарк под любую бизнес-модель и область применения.
Все это стало возможным благодаря тому, что язык С стандартизирован, любой может взять стандарт и написать под него компилятор. С Rust же это невозможно в принципе, просто потому что стандарта нет и не планируется. По сути Rust = rustc, и это достаточно серьезное ограничение для языка, который хочет захватить мир.
Ну, например, кроме крохотной кучки энтузиастов, увидевших в Rust будущее индустрии, на него нужно пересадить еще производителей железа, огромное сообщество Linux и игровую индустрию (последнее — C++, но это дела не меняет). И так далее, дополнять можно еще долго. Каков процент вероятности, что это произойдёт?
Аргументы есть. Как упомянуто в статье в эмбеденщине очень важно понимание кода всем и вся в т.ч. и не программистами. А я вот Rust с трудом воспринимаю с 10 летним опытом на C/C++, Python, а уж разработчики железа и плисовики точно его не поймут. Он только обманчиво визуально похож на С подобный, а под капотом вся эта концепция теории типов "для отличников". Язык конечно суперский, но очень дорогой для повсеместной разработки. Требует много сосредоточения на языке, а не на задаче. В эмбеденщине нет и не будет столько бабла как в оптимизации товаров и услуг, чтобы содержать для каждой железяки по гуру. Да и где их столько взять? Поэтому всем понятный, как язык общения, простой "код лапша" на C до нескольких тыс. строк еще долго будет объединять вокруг железяки эникейщиков для скорейшей генерации идеи пока она не успела выветриться из шальной головы ардуинщика.
Rust какой-то "инопланетный" и многословный, что ли. Хорошо, если он "взлетит", но сейчас попытки его использования оставляют странные впечатления. Он почему-то отпугивает больше, чем любой из C, C++, Java, Scala, Python, Lua, Delphi, R, Haskell.
Засунуть в одну копилку R, Hashell, Delphi и скриптовые языки это сильно :)
Хаскель отпугивает намного сильнее, моё мнение. По крайней мере его я освоить так и не мог, а с растом спокойно подружился — достаточно прочитать растбук. Из сложных концепций можно разве что лайфтаймы назвать, но стоит понять, что это просто декларативный способ указания отношений «Х живет дольше У» и все становится очевидно.
Хаскель отпугивает намного сильнее, моё мнение. По крайней мере его я освоить так и не мог, а с растом спокойно подружился — достаточно прочитать растбук. Из сложных концепций можно разве что лайфтаймы назвать, но стоит понять, что это просто декларативный способ указания отношений «Х живет дольше У» и все становится очевидно.
UFO just landed and posted this here
Да особо рассказывать нечего. Поставил IDE, начал смотреть примеры, книжки, статьи. Не сказать, что что-то непонятно: опыт F# у меня, например, уже был, как и лиспов всяких. Но как-то не зашло. Хотя я как раз хотел проникнуться всей мощью IO монад и прочих методов гамбургера. Мб попробую еще раз позже. Сейчас приоритет — научиться писать на расте :)
попытки его использования оставляют странные впечатления
Надо ли полагать, что это из-за его главной фичи? Которая ownership. Такого действительно нет в других ЯП.
По сравнению с C++ Rust не многословен. И там и там приянто полностью прописывать пространства имен, но в библиотеках Rust они организованы более продумано и лучше работает вывод типов.
Меня смущает, что допускают публиковать дубликаты.
И кстати, это не первый перевод, мягко говоря, давней статьи.
тоже самое
PS: искал инфу про С, случайно напоролся.
И кстати, это не первый перевод, мягко говоря, давней статьи.
тоже самое
PS: искал инфу про С, случайно напоролся.
Это вам нельзя. А тем кто ведет корпоративный блог, наверное, можно. Вообще-то надоели эти статьи в духе КО от крупных контор, которые на самом деле просто пиарятся
Вот бы движок хабра позволял искать по урл оригинала или имени автора — не было бы и дубликатов. Способ «случайно напоролся» — единственно возможный вариант найти уже существующий перевод.
> Миром управляют не массоны.
Массоны — это такие масоны, которые пишут на С.
Массоны — это такие масоны, которые пишут на С.
Имхо, почти про любой язык из TOP-10 Tiobe Index (ладно, TOP-5) можно сказать, что он "управляет миром". У них нет многих преимуществ C, но есть масса других преимуществ.
Какая-то односторонняя статья. Создаёт впечатление, что других языков почти нет, или они не работают.
Embedded-разработка
Замечаю, что в этом деле все больше набирает обороты С++.
Часто не используются классы, но код все же именно на С++ (используются фишки именно этого языка).
Да и классы тоже частенько стали пользовать.
Даже ардуина программируется на С++ (даром что Wiring, но это всего лишь библиотека-обертка).
Оверхед C++ всё же отключается, и да, при системной и embedded разработке на C++ стандартная библиотека заменяется специально спроектированной под нужную среду. В целом на сегодняшний день нет смысла что-либо писать на си, любую задачу, выполнимую на си можно выполнить и на плюсах (каком-то его подмножестве, но в любом случае это будет удобнее). Проблема обычно только в наличии специалистов с нужной компетенцией, для таких задач все особенности языка и его рантайма нужно знать досконально.
В советские времена слышал высказывание «Язык C придуман западными программистами для борьбы с капиталистическими эксплуататорами»… а в 90х видел комментарий в коде «на C писать — идиотом стать»
А я не люблю C. В нём нет защиты от дурака и он стар. А бы писал на нём только для embedded решений, где каждый байт на счету. Хотя я уверен, что если бы был процедурный язык, который устранил бы недостатки С и добавил бы синтаксического сахара, то C «умер» бы очень быстро…
От дурака никакая защита не спасет. Чем ниже порог вхождения в технологию, тем более бестолковые люди придут в IT.
Ну в ИТ уже много бестолковых пришло, но от этого толковых меньше не стало, а их ценность только повысилась. А про защиту от дурака могу сказать одно — "=" в условиях. Кому нужно присваивать что либо в условиях?! Почему разработчики языка сразу не заблокировали этот источник ошибок?! А таких вещей в С очень много… И именно поэтому я его и не люблю…
Кому нужно присваивать что либо в условиях?!Ну, сишники любят лаконичные циклы, например
while ((nbytes = getline(&buffer, &bufsiz, fp)) != -1) {...}if ( B *b = dynamic_cast<B*>(a) ) {...}Честно говоря, на практике никогда не сталкивался с подобными ошибками. Тем более, что современные статические анализаторы умеют отыскивать потенциальные ошибки с присваиванием.
Откуда мысль, что защита от дурака сильно снижает порог вхождения? Вот скажем хорошо защищенный язык ATS сможет освоить не каждый плюсовик и ембедщик. Да и Rust все-таки сложнее чистых C.
Очевидный вывод из того, что при прочих равных снижается количество факторов, которые необходимо учитывать.
Факторов меньше не становится. Просто компилятор вовремя сообщает, что какой-то фактор неучтен.
Зачем глубже изучать технологию и читать блоги с умными советами, если компилятор/рантайм и так покажет в чем беда еще до того?
Что бы понимать, что компилятору не понравилось.
Мой компилятор обычно пишет причину и даже указывает предполагаемое место проблемы, а рантайм бросает исключения, которые подробно описаны в референсе. А ваш?)
Это компенсация за то, что он не может найти более серьезных ошибок. А вот над сообщением, что два выведенных типа не отождествляются, или время жизни переменной не соотвествует ожиданиям, голову прихолится поломать, несмотря на достаточно качественную диагностику.
Компилятор не может и не должен искать логические ошибки.
От дурака никакая защита не спасет.
Логическая ошибка — это поделить на два там, где нужно умножить, перепутать дату рождения с датой регистрации или еще что-то в этом духе. От этого компилятор действительно не может спасти.
Ошибки же управления ресурсами — это другое, и как показывает мой скромный опыт с Rust, тут компилятор способен очень на многое. Но понимать, что как работает, все равно нужно: компилятор выдает чаще ошибки вида «сходи-ка дружок поучи матчасть», чем «сделай как я говорю, и все заработает».
Ошибки же управления ресурсами — это другое, и как показывает мой скромный опыт с Rust, тут компилятор способен очень на многое. Но понимать, что как работает, все равно нужно: компилятор выдает чаще ошибки вида «сходи-ка дружок поучи матчасть», чем «сделай как я говорю, и все заработает».
В контексте обсуждения, это (попытка управлять выносить бизнес-логику в компилятор) как раз повышает сложность: необходимо придерживаться некоторых правил и уметь читать ошибки. Такой себе встроенный «фреймворк» со статическими тестами.
Можно по-разному понимать «защиту от дурака», наверное. Java, например, реализует такой способ защиты, который позволяет дураку программисту не думать о многих вещах, а Rust (не знаю про ATS) именно заставляет его подумать, и еще доказать компилятору, что хорошо подумал. Это заставляет повозиться, да.
Этот язык просто попал в классическую ловушку — для него написано слишком много библиотек чтобы от него можно было отказаться и в то же время по этой же причине никто не будет писать аналогичные библиотеки для других языков. ИМХО лучше было бы чтобы победил именно паскаль. Если бы его развивали, сейчас по свойствам был бы на том же уровне что и С но более выразительный. Просто видимо изначально кому-то не понравилось много писать begin-end и подкупили краткие скобочки {} языка С, но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.
UFO just landed and posted this here
Скобочки это хорошо и намного более короче и нагляднее, чем begin-end. А вот настоящий ад C — это всё что связано с указателями (*, ^ и т.д.), а также особая любовь к _ в названиях переменных и функций, а также разбавление кода знаками вроде <>, # и % Из-за этого код C выглядит как набор символов. Добавьте к этому не очень явное наименование стандартных функций вроде scanf или puts и получится мощный язык, на котором не очень-то хочется писать…
Паскаль гораздо конвервативнее, чем C.
Так разделение statement/expression в нем заметно более выраженое, а современная тенденция как раз в сторону expression-based языков.
На тот момент все-таки C был лучшим выбором, просто не надо было делать его окончательным.
Так разделение statement/expression в нем заметно более выраженое, а современная тенденция как раз в сторону expression-based языков.
На тот момент все-таки C был лучшим выбором, просто не надо было делать его окончательным.
У Паскаля несколько тяжёлых недостатков, которые его по сути и убили, jIMHO, а в общем он просто сырой. Можно посмотреть на то, какими получились языки линии Modula, в которых некоторые самые тяжёлые проблемы были устранены.
Самое серьёзное — это стиль ввода-вывода. Язык явно задаёт особый стиль для read[ln]/write[ln], со всеми этими write(x:10:5). Программисту сделать свою функцию, которая будет уметь то же самое, нельзя. Сделать различие write() для stdout и write() для заданного хэндла — тоже нельзя. Сделать средствами языка свою реализацию файлов — тоже нельзя. В C — можно. Этого фактора было достаточно, чтобы слой хакеров (в реймондовском смысле) категорически отверг Паскаль и стал смотреть в сторону Си, у которого таких ограничений нет. Причём это не исправлено, насколько мне известно, даже в современных активно развиваемых реализациях! хотя могли давно придумать какие-то макросы, например.
Большая группа проблем при изучении языка (а каждая такая проблема вылазит и у профессионала, если он устал или не сосредоточен!) Я провёл через это нескольких школьников, пишу по своим впечатлениям:
Вечная борьба с блоковыми скобками — ставить begin/end или не ставить, ставить ';' перед else или не ставить, ставить перед end или не ставить (а некоторые психи настаивали, что перед end нельзя ставить ';')… И портит картину то, что постоянно эти скобки пропускаются в примерах и учителями, а понять, как их расставлять — например, как после then и после else раздельно ставить, или не ставить — это для совсем юных очень сложно.
В Си за счёт более коротких скобок эта проблема замаскирована, но осталась. В Modula — имплицитное begin и обязательное end — это один из лучших вариантов стиля. Go/Swift/Perl/etc. с форсированием {}, Python с отступами — это всё решения лучше, чем в Паскале. Для обучения вообще форсирование отступов очень полезно для формирования стиля.
Ещё сбивает с толку то, что repeat — until это само по себе скобки, а все прочие — нет.
И снова те же read[ln], write[ln] — тут пиши файл, а тут рыбу заворачивай — у школьников головы дымятся, у профессионалов тоже. Разделение printf/fprintf как в C — сильно лучше.
Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).
Никлаус Вирт орал на весь мир «Не используйте Паскаль! Есть Modula, есть Oberon, в них все дурости Паскаля исправлены!», но так как в IT почти всегда идёт в массы не лучшее, а первое из минимально приемлемых, то застрял Паскаль.
> но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.
От begin-end рябит в разы хуже, потому что читается медленнее. И, повторюсь, блоковые скобки лучше форсировать даже для одного оператора — мировая практика постепенно пришла к этому. Сразу уходит куча дурных проблем типа «висячий не там else» или «тут воткнул ещё один оператор в теле под if, а почему старый перестал выполняться по условию?» Можно спорить, как именно должны выглядеть эти скобки, но они должны быть.
Самое серьёзное — это стиль ввода-вывода. Язык явно задаёт особый стиль для read[ln]/write[ln], со всеми этими write(x:10:5). Программисту сделать свою функцию, которая будет уметь то же самое, нельзя. Сделать различие write() для stdout и write() для заданного хэндла — тоже нельзя. Сделать средствами языка свою реализацию файлов — тоже нельзя. В C — можно. Этого фактора было достаточно, чтобы слой хакеров (в реймондовском смысле) категорически отверг Паскаль и стал смотреть в сторону Си, у которого таких ограничений нет. Причём это не исправлено, насколько мне известно, даже в современных активно развиваемых реализациях! хотя могли давно придумать какие-то макросы, например.
Большая группа проблем при изучении языка (а каждая такая проблема вылазит и у профессионала, если он устал или не сосредоточен!) Я провёл через это нескольких школьников, пишу по своим впечатлениям:
Вечная борьба с блоковыми скобками — ставить begin/end или не ставить, ставить ';' перед else или не ставить, ставить перед end или не ставить (а некоторые психи настаивали, что перед end нельзя ставить ';')… И портит картину то, что постоянно эти скобки пропускаются в примерах и учителями, а понять, как их расставлять — например, как после then и после else раздельно ставить, или не ставить — это для совсем юных очень сложно.
В Си за счёт более коротких скобок эта проблема замаскирована, но осталась. В Modula — имплицитное begin и обязательное end — это один из лучших вариантов стиля. Go/Swift/Perl/etc. с форсированием {}, Python с отступами — это всё решения лучше, чем в Паскале. Для обучения вообще форсирование отступов очень полезно для формирования стиля.
Ещё сбивает с толку то, что repeat — until это само по себе скобки, а все прочие — нет.
И снова те же read[ln], write[ln] — тут пиши файл, а тут рыбу заворачивай — у школьников головы дымятся, у профессионалов тоже. Разделение printf/fprintf как в C — сильно лучше.
Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).
Никлаус Вирт орал на весь мир «Не используйте Паскаль! Есть Modula, есть Oberon, в них все дурости Паскаля исправлены!», но так как в IT почти всегда идёт в массы не лучшее, а первое из минимально приемлемых, то застрял Паскаль.
> но это как раз и есть АД си-шечки — в более-менее сложных программах просто в глазах рябит от этих скобочек.
От begin-end рябит в разы хуже, потому что читается медленнее. И, повторюсь, блоковые скобки лучше форсировать даже для одного оператора — мировая практика постепенно пришла к этому. Сразу уходит куча дурных проблем типа «висячий не там else» или «тут воткнул ещё один оператор в теле под if, а почему старый перестал выполняться по условию?» Можно спорить, как именно должны выглядеть эти скобки, но они должны быть.
Чего пенять на стиль ввода-вывода, если он стал «Deprecated» ещё в самом турбопаскале… и не убрали их лишь из вопроса совместимости. Сейчас файловый ввод-вывод осуществляется исключительно через объекты. Более того, даже пришлось немного покорёжить обратную совместимость старые функции открытия/закрытия файла создали интерференцию с другими функциями стандартных классов. Аналоги функций с переменным количеством аргументов появлялись в последних версиях турбопаскаля, когда там даже динамических массивов ещё небыло.
А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками, паскаль просто подталкивает к этому порождая полезные привычки. Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций. Инженерный и бухгалтерский калькулятор могут дать разный результат из-за разного приоритета операций. Классическое 1+2*2 какой-то калькулятор даст 5 а другой 6… и поди пойми их! и ещё ньюанс «1+2(2+3)» и «1+2*(2+3)» могут быть посчитаны по-разному. Как в таком мире жить?
А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками, паскаль просто подталкивает к этому порождая полезные привычки. Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций. Инженерный и бухгалтерский калькулятор могут дать разный результат из-за разного приоритета операций. Классическое 1+2*2 какой-то калькулятор даст 5 а другой 6… и поди пойми их! и ещё ньюанс «1+2(2+3)» и «1+2*(2+3)» могут быть посчитаны по-разному. Как в таком мире жить?
Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций.Характерной особенностью инженерного является возможность вводить скобочки. Стандартный же не умеет считать выражения (только отдельные операции), поэтому приоритетов у него нет вообще.
> Аналоги функций с переменным количеством аргументов появлялись в последних версиях турбопаскаля, когда там даже динамических массивов ещё небыло.
Ну да, когда поезд ушёл — тенденция перехода на C стала массовой.
> А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками, паскаль просто подталкивает к этому порождая полезные привычки.
Извините, я не могу этот совет рассматривать всерьёз. Всегда есть какие-то естественные приоритеты, которым желательно не противоречить. В том же C, кстати, есть свои диверсии — исправленные в языках последних времён (см. таблицы приоритетов операций C и Go).
> Как в таком мире жить?
Улучшать. При любой возможности.
Ну да, когда поезд ушёл — тенденция перехода на C стала массовой.
> А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками, паскаль просто подталкивает к этому порождая полезные привычки.
Извините, я не могу этот совет рассматривать всерьёз. Всегда есть какие-то естественные приоритеты, которым желательно не противоречить. В том же C, кстати, есть свои диверсии — исправленные в языках последних времён (см. таблицы приоритетов операций C и Go).
> Как в таком мире жить?
Улучшать. При любой возможности.
> Взять даже обычные калькуляторы — оказывается, даже у них нет единого стандарта по приоритету операций.
Я знаю эту проблему, но это какое-то очень специфичное виндовое злонаследие. И именно оно показывает, что POLA лучше выполнять, где нет явных причин не делать это. Нормальный калькулятор с приоритетами сейчас укладывается в пару сотен строк кода. Если им нужно таки сохранять совместимость с древними багами, то лучше было бы переименовать «простой» режим в какой-нибудь dumb.
А неадекватные приоритеты в языках постоянно лечат, где нет необходимости сохранять старые баги. В C приоритет у &, | был занижен неадекватно — ниже сравнений. В Go, Swift — & на уровне с "*" "/", | — на уровне с "+" "-" — это уже не провокация, количество ошибок от нарушенных ожиданий резко ниже.
> А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками
Вы реально расставляете скобки даже в выражениях типа a*b+c за пределами виндового калькулятора? Позвольте не поверить…
Я знаю эту проблему, но это какое-то очень специфичное виндовое злонаследие. И именно оно показывает, что POLA лучше выполнять, где нет явных причин не делать это. Нормальный калькулятор с приоритетами сейчас укладывается в пару сотен строк кода. Если им нужно таки сохранять совместимость с древними багами, то лучше было бы переименовать «простой» режим в какой-нибудь dumb.
А неадекватные приоритеты в языках постоянно лечат, где нет необходимости сохранять старые баги. В C приоритет у &, | был занижен неадекватно — ниже сравнений. В Go, Swift — & на уровне с "*" "/", | — на уровне с "+" "-" — это уже не провокация, количество ошибок от нарушенных ожиданий резко ниже.
> А насчет выражений, так в любом языке лучше расставить приоритеты явно скобками
Вы реально расставляете скобки даже в выражениях типа a*b+c за пределами виндового калькулятора? Позвольте не поверить…
Самое серьёзное — это стиль ввода-вывода
Это — надуманная претензия. Никто не запрещает вам отказаться от встроенных средств и использовать библиотеки в стиле Си.
Для обучения вообще форсирование отступов очень полезно для формирования стиля.
Есть best practises и style guide. И никаких споров.
И снова те же read[ln], write[ln] — тут пиши файл, а тут рыбу заворачивай — у школьников головы дымятся, у профессионалов тоже. Разделение printf/fprintf как в C — сильно лучше.
Как раз наоборот: то, что все работает с handle'ами — замечательно, и хорошо ложится, например, на подсистему ввода-вывода NT. Вот у тебя хендл — используй его для вывода. А что там под хендлом смонтировано — файл, консоль. конвейер — неважно.
Вечная идиотская проблема с тем, что and, or приоритетнее сравнений, поэтому написать a=b and c=d нельзя, нужно (a=b) and (c=d).
И замечательно — второй вариант читается лучше.
От begin-end рябит в разы хуже, потому что читается медленнее.
Строго наоборот — они лучше «отчеркивают» блоки. Естественно, если используются примерно так же, как скобки в С в GNU style, т.е. каждый begin и end строго на отдельной строке с соблюдением отступов.
Сразу уходит куча дурных проблем типа «висячий не там else» или «тут воткнул ещё один оператор в теле под if, а почему старый перестал выполняться по условию?»
Скорее это проблема тех, кто работает с Python или просто новичок. Ни разу за уже 9 лет работы с Delphi (Object Pascal т.е.) такого не было.
Остальное все вкусовщина — кто к чему привык.
> Это — надуманная претензия. Никто не запрещает вам отказаться от встроенных средств и использовать библиотеки в стиле Си.
И вы отказываетесь читать то, что написано прямым текстом.
Сейчас, да, есть подобные библиотеки, и их можно использовать. Тогда — не было. Поезд ушёл тогда, до середины 90-х, а не сейчас.
> Как раз наоборот: то, что все работает с handle'ами — замечательно,
И во второй раз не хотите читать. Проблема не в самой работе с хэндлами, а в том, что в writeln с компанией или есть скрытый аргумент в виде stdout (или как он там зовётся в Паскале), или его нет.
> И замечательно — второй вариант читается лучше.
С такой аргументацией прямая дорога к Лиспу. У вас может сколько угодно «лучше читаться» второе, но если не ставить скобки, то ожидаемое не соответствует реальному.
> Строго наоборот — они лучше «отчеркивают» блоки.
Необязательные begin-end — худший вариант из четырёх рассмотренных.
> Естественно, если используются примерно так же, как скобки в С в GNU style, т.е. каждый begin и end строго на отдельной строке с соблюдением отступов.
А со стилем Modula/Ruby/etc., например, не надо ставить таких искусственных условий.
> Скорее это проблема тех, кто работает с Python или просто новичок.
Вы не в теме. Проблема висячего else это проблема, которая известна давно до появления Python (а в Питоне её не может быть по определению). А что «просто новичок» — согласен, профессионал, пару раз обжёгшись, просто введёт принцип «скобки обязаны быть всегда».
> Ни разу за уже 9 лет работы с Delphi (Object Pascal т.е.) такого не было.
А у меня было, когда с ним работал. И у тех, кто сейчас учится — постоянная проблема.
> Остальное все вкусовщина — кто к чему привык.
«Остального» не было, но статистика вкусовщины это уже не вкусовщина. А по ней таки упорно движутся в сторону тех подходов, что я описал как исправленные. Только паскалисты продолжают цепляться за своё легаси, хотя даже автор языка давно советует обновиться.
И вы отказываетесь читать то, что написано прямым текстом.
Сейчас, да, есть подобные библиотеки, и их можно использовать. Тогда — не было. Поезд ушёл тогда, до середины 90-х, а не сейчас.
> Как раз наоборот: то, что все работает с handle'ами — замечательно,
И во второй раз не хотите читать. Проблема не в самой работе с хэндлами, а в том, что в writeln с компанией или есть скрытый аргумент в виде stdout (или как он там зовётся в Паскале), или его нет.
> И замечательно — второй вариант читается лучше.
С такой аргументацией прямая дорога к Лиспу. У вас может сколько угодно «лучше читаться» второе, но если не ставить скобки, то ожидаемое не соответствует реальному.
> Строго наоборот — они лучше «отчеркивают» блоки.
Необязательные begin-end — худший вариант из четырёх рассмотренных.
> Естественно, если используются примерно так же, как скобки в С в GNU style, т.е. каждый begin и end строго на отдельной строке с соблюдением отступов.
А со стилем Modula/Ruby/etc., например, не надо ставить таких искусственных условий.
> Скорее это проблема тех, кто работает с Python или просто новичок.
Вы не в теме. Проблема висячего else это проблема, которая известна давно до появления Python (а в Питоне её не может быть по определению). А что «просто новичок» — согласен, профессионал, пару раз обжёгшись, просто введёт принцип «скобки обязаны быть всегда».
> Ни разу за уже 9 лет работы с Delphi (Object Pascal т.е.) такого не было.
А у меня было, когда с ним работал. И у тех, кто сейчас учится — постоянная проблема.
> Остальное все вкусовщина — кто к чему привык.
«Остального» не было, но статистика вкусовщины это уже не вкусовщина. А по ней таки упорно движутся в сторону тех подходов, что я описал как исправленные. Только паскалисты продолжают цепляться за своё легаси, хотя даже автор языка давно советует обновиться.
И вы отказываетесь читать то, что написано прямым текстом.
Сейчас, да, есть подобные библиотеки, и их можно использовать. Тогда — не было. Поезд ушёл тогда, до середины 90-х, а не сейчас.
Паскаль в той или иной ипостаси существует и поныне. А смысла в претензиях к версиям давно минувших дней — немного.
И во второй раз не хотите читать. Проблема не в самой работе с хэндлами, а в том, что в writeln с компанией или есть скрытый аргумент в виде stdout (или как он там зовётся в Паскале), или его нет.
В этом нет никакой проблемы — это можно считать вариацией неопределенного списка параметров/необязательных параметров.
С такой аргументацией прямая дорога к Лиспу. У вас может сколько угодно «лучше читаться» второе, но если не ставить скобки, то ожидаемое не соответствует реальному.
Ваши некорректные ожидания — ваша проблема. С такими аргументами вы можете требовать, чтобы программа работала корректно, несмотря на ваши логические ошибки — вы же ожидали иное.
Необязательные begin-end — худший вариант из четырёх рассмотренных.
Отнюдь. Это снижет количество визуального мусора, делает код более компактным без потери читаемости. Все проблемы вида «я добавил действие, а оно почему-то не выполнилось» — то же самое некорректное ожидание с вашей стороны. Единые правила оформления кода позволяют избавиться от львиной доли таких «проблем».
А со стилем Modula/Ruby/etc., например, не надо ставить таких искусственных условий.
По большому счету — это просто еще одно правило для автоформатера.
Вы не в теме. Проблема висячего else это проблема, которая известна давно до появления Python (а в Питоне её не может быть по определению).
Нет, это вы не поняли. Мой ответ относился ко второй вашей фразе, а не к висящему else.
А у меня было, когда с ним работал. И у тех, кто сейчас учится — постоянная проблема.
Здесь нет предмета для спора — у вас свой опыт, у меня свой. Разные команды, разные правила, разная среда, разный результат — кто-то так не обжигается, а кто-то во весь рост.
«Остального» не было, но статистика вкусовщины это уже не вкусовщина
Было. Отнюдь, это остается вкусовщиной, и то, что мейнстрим пошел в другом направлении, само по себе ничего не значит. У некоего языка есть набор параметров, преимуществ и недостатков. И если по тем или иным обстоятельствам язык Х потерял рынок и ушел на обочину, это вовсе не означает, что все его свойства и особенности (включая синтаксис) плохи.
> Паскаль в той или иной ипостаси существует и поныне. А смысла в претензиях к версиям давно минувших дней — немного.
Ага, «существует». В следовых количествах.
> В этом нет никакой проблемы — это можно считать вариацией неопределенного списка параметров/необязательных параметров.
Когда нельзя самому такое сделать — это не вариация неопределённого списка, это другое, недоступное.
> Ваши некорректные ожидания — ваша проблема.
Ожидания совершенно корректные и конкретные — эргономические и POLA.
> Это снижет количество визуального мусора, делает код более компактным без потери читаемости.
Среди рассмотренных четырёх вариантов опциональные begin-end — самый мусорный вариант.
> Нет, это вы не поняли. Мой ответ относился ко второй вашей фразе, а не к висящему else.
Принципиально проблема не меняется. Посмотрите тут рядом рассказы от PVS-Studio — случаев «забыли обернуть в скобки», мягко говоря, дофига.
Питонист тут как раз скорее сам всегда будет ставить скобки, для страховки.
> И если по тем или иным обстоятельствам язык Х потерял рынок и ушел на обочину, это вовсе не означает, что все его свойства и особенности (включая синтаксис) плохи.
Про «все» я и не говорил. Но упомянул те, которые однозначно плохи.
Ага, «существует». В следовых количествах.
> В этом нет никакой проблемы — это можно считать вариацией неопределенного списка параметров/необязательных параметров.
Когда нельзя самому такое сделать — это не вариация неопределённого списка, это другое, недоступное.
> Ваши некорректные ожидания — ваша проблема.
Ожидания совершенно корректные и конкретные — эргономические и POLA.
> Это снижет количество визуального мусора, делает код более компактным без потери читаемости.
Среди рассмотренных четырёх вариантов опциональные begin-end — самый мусорный вариант.
> Нет, это вы не поняли. Мой ответ относился ко второй вашей фразе, а не к висящему else.
Принципиально проблема не меняется. Посмотрите тут рядом рассказы от PVS-Studio — случаев «забыли обернуть в скобки», мягко говоря, дофига.
Питонист тут как раз скорее сам всегда будет ставить скобки, для страховки.
> И если по тем или иным обстоятельствам язык Х потерял рынок и ушел на обочину, это вовсе не означает, что все его свойства и особенности (включая синтаксис) плохи.
Про «все» я и не говорил. Но упомянул те, которые однозначно плохи.
UFO just landed and posted this here
Да и самому мне они претят, уродливо выглядит оно как-то.
Мне тоже немного не нравятся. Но я осознаю, что это вопрос привычки. А объективная польза от них достаточно высока, чтобы это терпеть.
у которых за плечами лет 40 опыта, и которые не ставят скобки вокруг однострочных тел, я встречался
С 40 годами опыта можно наловчиться перечитывать код и на эту тему. Но это непродуктивный подход — тратиться на то, что лучше обеспечит машина.
А чем Rust не такой язык?
Язык С не так сложно выучить, а вот польза от этого может быть существенная.
Наверное стоило бы добавить — «однако писать на нём очень не просто».
Прадед мой лопухом подтирался.
Дед мой лопухом подтирался.
Отец мой лопухом подтирался.
Я сам лопухом всю жизнь подтирался.
И тебе, сынок, придется.
Дед мой лопухом подтирался.
Отец мой лопухом подтирался.
Я сам лопухом всю жизнь подтирался.
И тебе, сынок, придется.
Спят подружки вредные
Безмятежным сном.
Снятся мышкам хлебные
Крошки под столом,
Буратинам — досточки,
Кошкам — караси,
Всем собакам — косточки,
Программистам — Си.
Безмятежным сном.
Снятся мышкам хлебные
Крошки под столом,
Буратинам — досточки,
Кошкам — караси,
Всем собакам — косточки,
Программистам — Си.
UFO just landed and posted this here
Кроме того, большинство пользуется раскладкой клавиатуры QWERTY. Вот только не потому, что эта раскладка лучше всех прочих предотвращает сцепление рычагов в пишущих машинках или наиболее удобна для печати, а потому что так сложилось исторически.
Впрочем, не все довольны возможностями, предоставляемыми C. Microsoft использует SAL (source-code annotation language) в драйверах, API и, надо полагать, в ядре. SAL позволяет в машиночитаемой форме сказать что-то вроде: "Этот параметр — не просто указатель, а указатель на массив, длина которого содержится вот в этом параметре", а также многое другое.
Дополнение. QWERTY не предотвращает сцепление рычагов (клавиши E и R для часто встречающегося в английском "er" расположены рядом) и не самая удобная раскладка для печати.
Емнип, ходит легенда про то, что на высокой скорости печати соответствующие узлы ломались/стопорились и для этого сделали искусственное замедление скорости печати.
Но мне больше нравится легенда о том, что это сделано было в рекламных целях — что бы название конторы, выпускающей первые машинки с QWERTY раскладкой можно было напечатать используя символы одного ряда клавиатуры.
Но мне больше нравится легенда о том, что это сделано было в рекламных целях — что бы название конторы, выпускающей первые машинки с QWERTY раскладкой можно было напечатать используя символы одного ряда клавиатуры.
UFO just landed and posted this here
Еще Redis, Nginx, SQLite, которые есть в большинстве проектов.
Более того, все промышленные «вещи» спроектированы в CAD системах, написанных на С/С++. Думаю С/С++ на сегодня самый лучший язык.
Все языки хороши, которыми владеешь. Это даёт гибкость в написании проектов и изучение нового здесь представляется необходимым.
Sign up to leave a comment.
Миром всё ещё управляет язык С