Если внимательно прочитайте, то речь шла о том, что за 7 лет существования Раста им пользуется только Мозилла, да 3.5 фанбоев — увы, но такова жестокая реальность :)
Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.
Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)
Ну как я слышал, Смоллтолк нынче больше популярен как обучающий язык программирования, т.к. все остальные ООП языки так или иначе испытывали его влияние. Но язык действительно не смог взлететь (ну по сравнению с С++, Жаба, C# и т.д.) — я хз почему, только могу предположить, мне кажется потому:
1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.
Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
Странно, не хватает еще скриншотов с IBM, Atlassian, Adobe, ну и т.д. по списку, пичалька, ну шо Вы ей Б-г прям как маленький — ищите и обрящите: https://github.com/golang/go/wiki/GoUsers
Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)
Показательно это то что Rust в продакшене не используется от слова «совсем» (ну допустим «почти совсем»), по крайней мере за пределами Мозилы и 3.5 фанбоев. В то время как на сабже написан тот же Докер, а пользуются всякие Атлласианы, Адобы, АйБиЭмы и прочие Дропбоксы, даже китайцы на нем пишут — вот это показательно.
Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)
Smalltalk в 2017 году? Увольте.
Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)
Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.
В общем, если не копаться в глубь (шо нынче не в моде), то существенной разницы не заметите:
|f|
"A comment"
f := Foo new: 'AString';
Foo f;
// A comment
f = new Foo("AString");
Разница просто гигантская, не правда ли? :-)
initReports
"Initialize the list of reports by reparsing the index file."
| parser |
self resetReports.
parser := IndexFileParser
documentBase: self documentBase
source: self getIndexFileStream.
[parser atEnd]
whileFalse: [self addReport: parser next]
/*
* Initialize the list of reports by reparsing the index file.
*/
public void initReports(String reportBase)
{
IndexFileParser parser;
Report report;
resetReports();
parser = new IndexFileParser(getDocumentBase(), getIndexFileStream());
while ((report = getNextReport(parser)) != null) {
addReport(report);
}
}
Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
Вероятно просто у Оракла индусов больше чем классов, так что если кто-то что-то сломает на самом верху этой 5-и уровненной пирамидки, то они просто натравят всю эту ораву прилаживать костыли. В принципе им должно хватить всех сотрудников, шоб натравить на пирамидку из 12 ступенек наследования. А так-то большинство паттернов содержат 2-3 слоя наследования, ну было дело -пришлось как-то забацать 4 иерархии наследования (крайне специфическая задача). А все что 5+ ИМХО просто отсутствие архитектуры, клацц-клац и в продакшен, а рефакторинг для трусов, а может просто разработчики писали калькулятор для конкурса сайта http://govnokod.ru
Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.
Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.
Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.
А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…
На XXII съезде КПСС обещали построить коммунизм к 1980 году… но коммунизм так не построили, поэтому решили изобрести ООП и сказать, что вот оно счастье. Приверженцы этой новой парадигмы обещали возможность создания повторно используемых классов и паттернов, и это звучало заманчиво. Возможность комбинировать эти классы в многократно используемые и настраиваемые бизнес компоненты казалась Святым Граалем индустрии ПО. (с — https://habrahabr.ru/post/143620/ )
Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
Вброс засчитан… осталось только выяснить, шо такое Rust и использует ли его хоть кто-нибудь, кроме Мозиллы для задач сложнее ХеллоуВорлда. Я вот только про игру с таким названием слышал, но сомневаюсь, что это хоть как-то связано с этим языком, его популярностью и применимостью…
Хз, наверное потому что за 30+ лет своего существования ООП так и не взлетела.
Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию
Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/
Потому что 99% кода написанного на Python это самые натуральные спагетти, такие, шо даже сам автор через пару месяцев не разберётся в своей лапше.
Потому что в коде написанном на Python постоянно происходит куча неявных преобразований и другой фигни, о которых автор кода даже не догадывается, ну а про тонны зарытых ошибок я вообще молчу.
Потому что этот код будут сопровождать и работать с ним другие люди, я, конечно, понимаю шо мне ничего не надо, лишь бы у соседа ничего не было, но какая-то культура должна быть…
Ну и потому что код на Питоне, это даже хуже кода на Матлабе (там хотя бы хоть какая-то проверка корректности тех же матричных операций присутствует).
Так что если у человека полностью отсутствует самодисциплина и аккуратность, то его даже близко нельзя подпускать к таким языкам, как Python и прочие ЖабаСкрипты.
На самом деле как были самыми главным сайнтифик языками C/C++ и Fortran, так они ими и остаются. Ну может еще Golang когда-нибудь взлетит.
Теперь по порядку. Магических и не общеупотребимых циферок в теле программы быть не должно в принципе. Например, вместо какой-то там 3.14..., должна быть константа Pi, а вместо циферки 64, которая постоянно встречается в этой статье в роли аргумента (а еще 256 и вообще, кто все эти цифры?), должна быть какая-то переменная с осмысленным именем, ибо я еще пока ниразу не встречал программиста-экстрасенса. Ну а если программист этого не понимает, ну я хз, наверное его стоит отправить в ссылку программировать на Паскале… Пока не научится.
Что касается имен, слышал я легенды, о том, что когда-то в древние-древние времена было ограничение на число символов в имени файла или в имени функции, но вроде бы к 21-ому веку эту проблему побороли. Так шо можно и больше 3-х букв использовать в именах: loss — норм, наверное это как-то связано с функцией потерь, а вот шо такое ksi — я даже хз, похоже на матерное слово… А может это маскировка под греческую букву, неизвестного назначения? Может угол какой-то? Конечно, доля смысла в использовании букв прям как в статье есть, только тогда потрудились описывать такие переменные комментариями в коде, как это принято в приличных статьях: where ksi — is random value, phi — is phase of oscillation. Я еще понимаю когда опять-таки используют общеупотребимых буквы, типа epsilon — диэлектрическая проницаемость, c-скорость света, h — постоянная планка… хотя код может быть посвящен термодинамике, где c уже окажется теплоемкостью…
Я кстати хз что такое Rust, знаю только шо игра есть такая, но если человек хоть немного слышал за Objective-C, Java, Golang, Erlang, Python, Scala, ну и C#, и коллеги еще подсказывают про Ruby, и всякие шаблоны проектирования, то про Smalltalk по любому должен был слышать, иначе возникает вопрос, а знает ли он вообще что такое ООП.
Собственно даже дети знают (но могут не подозревать) что такое Smalltalk, т.к. этот ЯП, его потомки или ЯП которые испытание его влияние, являются сейчас наверное основными учебными ЯП (например Scratch), по крайней мере за бугром. Так что знать про него, также как и про C, Pascal, Fortran, Lisp, Basic должны многие, вполне логично что это самый любимый язык.
Вы просто не в теме.
Там только сред разработки и реализаций языка (типа Дельфина или F-script) за пол сотни будет. Отличный распространенный обучающий язык, всяко получше всех этих бейсиков будет.
Я уж даже хз, вообще есть ли программисты которые на нем хоть раз не программированию?
Вообще это все глупо. Когда подбирал себе человека, просил одно из двух: пример проекта (куска проекта), удовлетворяющий определенным требованиям или решить мою задачу (максимально абстрактную) и выслать мне код. Это все до прихода человека на очное собеседование.
Он решил => я посмотрел и оценил => его пригласили и побеседовали о его решении задачи. Кагбэ на этом все.
К чему эти нудные опросы алгоритмов? Для этого есть книжки, книжка такое собеседование пройдет идеально. Все эти беспредметные разговоры (что-бы спросить, что-бы спросить… Ага… Спрошу его про Штрассена!). Чисто проверка на эрудиции. Эрудиция это хорошо, но не главное.
Выборы в парламент Франции не прямые и трехуровневые, не смотря на широкие полномочия, президент все делает с оглядкой на парламент, даже премьер-министр назначается от той партии, которая набрала большинство мест в парламенте (в противном случае лидирующая партия просто снимет правительство)
Непрямые выборы — единственная естественная система для федеративного государства, коим является США, т.к. субъектом голосования является именно штат, а не толпы студентов. В противном случае получим диктатуру большинства и безальтернативные выборы. Во Франции так вообще трехстепенные выборы.
Прямые выборы на самом деле становятся неактуальными если избирателей больше 3.5 человек.
Это в том числе. Но Фортран сам по себе очень приятный язык, сделанный для людей, без этих монструзных конструкций, так свойственным современным мейнстримовым языкам. Там уже куча всего из под коробки и оно отлично работает, не надо ломать голову над никому не нужным синтаксическим сахаром.
Ну и интересный момент — ни раз бывало, что фортрановский скомпилированный код получался на 5-10% быстрее кода на Си, при этом компилятор то один и тот же (интеловский)… ну т.е. для того что бы получить такой же быстрый код на Си надо серьезно поизвращаться.
Вот и получается, что по соотношению затраты/производительность, Фортран оказывается самым оптимальным. За бугром (особенно в США) он куда более распространен чем в РФ (в РФ я бы сказал про него почти никто не знает)
Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.
Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)
1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.
Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)
Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)
Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)
Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.
В общем, если не копаться в глубь (шо нынче не в моде), то существенной разницы не заметите:
Разница просто гигантская, не правда ли? :-)
Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
Впрочем порой он даже более читабелен:
Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.
Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.
Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.
А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…
Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
Впрочем их вообще не надо ни откуда наследовать, Data oriented design и композиция отлично справляется, но это уже нисколько не ООП :-)
Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию
Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/
Потому что в коде написанном на Python постоянно происходит куча неявных преобразований и другой фигни, о которых автор кода даже не догадывается, ну а про тонны зарытых ошибок я вообще молчу.
Потому что этот код будут сопровождать и работать с ним другие люди, я, конечно, понимаю шо мне ничего не надо, лишь бы у соседа ничего не было, но какая-то культура должна быть…
Ну и потому что код на Питоне, это даже хуже кода на Матлабе (там хотя бы хоть какая-то проверка корректности тех же матричных операций присутствует).
Так что если у человека полностью отсутствует самодисциплина и аккуратность, то его даже близко нельзя подпускать к таким языкам, как Python и прочие ЖабаСкрипты.
На самом деле как были самыми главным сайнтифик языками C/C++ и Fortran, так они ими и остаются. Ну может еще Golang когда-нибудь взлетит.
Теперь по порядку. Магических и не общеупотребимых циферок в теле программы быть не должно в принципе. Например, вместо какой-то там 3.14..., должна быть константа Pi, а вместо циферки 64, которая постоянно встречается в этой статье в роли аргумента (а еще 256 и вообще, кто все эти цифры?), должна быть какая-то переменная с осмысленным именем, ибо я еще пока ниразу не встречал программиста-экстрасенса. Ну а если программист этого не понимает, ну я хз, наверное его стоит отправить в ссылку программировать на Паскале… Пока не научится.
Что касается имен, слышал я легенды, о том, что когда-то в древние-древние времена было ограничение на число символов в имени файла или в имени функции, но вроде бы к 21-ому веку эту проблему побороли. Так шо можно и больше 3-х букв использовать в именах: loss — норм, наверное это как-то связано с функцией потерь, а вот шо такое ksi — я даже хз, похоже на матерное слово… А может это маскировка под греческую букву, неизвестного назначения? Может угол какой-то? Конечно, доля смысла в использовании букв прям как в статье есть, только тогда потрудились описывать такие переменные комментариями в коде, как это принято в приличных статьях: where ksi — is random value, phi — is phase of oscillation. Я еще понимаю когда опять-таки используют общеупотребимых буквы, типа epsilon — диэлектрическая проницаемость, c-скорость света, h — постоянная планка… хотя код может быть посвящен термодинамике, где c уже окажется теплоемкостью…
Собственно даже дети знают (но могут не подозревать) что такое Smalltalk, т.к. этот ЯП, его потомки или ЯП которые испытание его влияние, являются сейчас наверное основными учебными ЯП (например Scratch), по крайней мере за бугром. Так что знать про него, также как и про C, Pascal, Fortran, Lisp, Basic должны многие, вполне логично что это самый любимый язык.
Ну возможно кто-то и не знает…
Там только сред разработки и реализаций языка (типа Дельфина или F-script) за пол сотни будет. Отличный распространенный обучающий язык, всяко получше всех этих бейсиков будет.
Я уж даже хз, вообще есть ли программисты которые на нем хоть раз не программированию?
Он решил => я посмотрел и оценил => его пригласили и побеседовали о его решении задачи. Кагбэ на этом все.
К чему эти нудные опросы алгоритмов? Для этого есть книжки, книжка такое собеседование пройдет идеально. Все эти беспредметные разговоры (что-бы спросить, что-бы спросить… Ага… Спрошу его про Штрассена!). Чисто проверка на эрудиции. Эрудиция это хорошо, но не главное.
Выборы в парламент Франции не прямые и трехуровневые, не смотря на широкие полномочия, президент все делает с оглядкой на парламент, даже премьер-министр назначается от той партии, которая набрала большинство мест в парламенте (в противном случае лидирующая партия просто снимет правительство)
Прямые выборы на самом деле становятся неактуальными если избирателей больше 3.5 человек.
Ну и интересный момент — ни раз бывало, что фортрановский скомпилированный код получался на 5-10% быстрее кода на Си, при этом компилятор то один и тот же (интеловский)… ну т.е. для того что бы получить такой же быстрый код на Си надо серьезно поизвращаться.
Вот и получается, что по соотношению затраты/производительность, Фортран оказывается самым оптимальным. За бугром (особенно в США) он куда более распространен чем в РФ (в РФ я бы сказал про него почти никто не знает)