Изучив статистику 39 факультетов компьютерных наук различных ВУЗ-ов США, исследователи пришли к выводу (http://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the...), что Pythpn является наиболее востребованным языком программирования при преподавании вводных курсов. В частности, Python используется в начальных курсах обучения программированию (CS0 и CS1) в 8 из 10 самых крупных факультетов (80%) и в 27 из 39 в полной выборке факультетов (69%). На втором месте язык Java, который рассматривается в 22 курсах из 39, С и С++ изучается только в 6 курсах.<center><a href="http://cacm.acm.org/system/assets/0001/6470/Top39-700.3.png&... src="https://www.opennet.ru/opennews/pics_base/0_1404803885.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: http://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the...
Новость: https://www.opennet.ru/opennews/art.shtml?num=40159
америкосы хипуют
Америкосы изобрели все языки из списка и имеют польное право выбирать.
Язык РАПИРА им всё равно не освоить, пусть мучаются.
> Язык РАПИРА им всё равно не освоить, пусть мучаются.И КР580ВМ80А им не передрать. Ща мы их зарулим в области IT!
Если серьезно, то очень жаль РЕФАЛ, которому очень помешал железный занавес.
> Если серьезно, то очень жаль РЕФАЛ, которому очень помешал железный занавес.У наших вообще бывают удачные идеи, но бюрократия и волокита - все проcpaли. Специалистам оказывается проще свалить туда где можно заниматься своим делом, получать многозелени и не бороться с глупым начальством.
В данном случае всё очень осложнило занятие Турчина правозащитной деятельностью, приведшее в конце концов к его высылке. Так что, говорят, ученикам пришлось защищаться не только без упоминания его фамилии, но и названия самого языка.
> В данном случае всё очень осложнило занятие Турчина правозащитной деятельностьюНу так любят у нас когда все строем ходят, и чтобы точка зрения - единственно правильная. А то что это ведет к таким факапам - можно и не обращать внимание. Нефти и газа у нас много, лет на хренадцать еще хватит, а там хоть потоп.
> Ну так любят у нас когда все строем ходят, и чтобы
> точка зрения - единственно правильная.Можно подумать на западе не так.
> Можно подумать на западе не так.Судя по наблюдаемому - раз на раз не приходится, но в целом климат получше. Было бы тут все хорошо, яндекс бы содержал головной офис здесь, да и nginx, inc пожалуй был бы местной компанией. И Дуров не пролетал бы на свой бизнес, в назидание остальным. А теперь вот он почему-то смотрится на фоне Брина и Цукерберга лохом у которого отжали бизнес...
>> Ну так любят у нас когда все строем ходят, и чтобы
>> точка зрения - единственно правильная.
> Можно подумать на западе не так.прикинь, не так. но ты продолжай смотреть киселёва, он правду говорит.
Чем помешал железный занавес Рефалу? Создатель Рефала Валентин Турчин после письма написанного вместе с Д.Сахаровым и Роем Медведевым "Письмо руководителям партии и правительства" после предупреждения КГБ был вынужден выехать за границу в США ещё в 1977 году! Сахарова потом держали в Горьком под домашним арестом. Медведев не знаю как пострадал.
Интересное письмо - я думал мы начали отставать в электронике только к началу перестройки, а оказывается ещё в начале 70х уже прилично отставали. Ну и вдрух отраслях тоже отставали на порядки или в разы.
Вот ссылка на письмо http://ru.wikisource.org/wiki/%D0%9F%D0%...
> Интересное письмо - я думал мы начали отставать в электронике только к
> началу перестройки, а оказывается ещё в начале 70х уже приличноТы еще почитай что в СССР думали про кибернетику и т.п..
Python изобрёл голландец
Не надо ля-ля, Питон изобрели марсиане, ибо только на Mарсе пробелы и табы видимы!
> Америкосы изобрели все языки из списка и имеют польное право выбирать.Это несколько опрометчивое заявление:
> Разработка языка Python была начата в конце 1980-х годов[8] сотрудником голландского института CWI Гвидо ван Россумом.
Но Гвидо ван Россум жеж родился и вырос в Нидерландах, где он закончил Амстердамский университет и создал его как ЯП по обучению программированию в Голландском НИИ.
Американцы такие американцы :)
Страуструп - датчанин, Гослинг - канадец.
А язык у них - вообще английский!
> А язык у них - вообще английский!А вы я так смотрю оптимист. Шигорин вон тут как-то приводил пример "читаемого" кода на питоне. Там почти все на японском было. Форматирование, конечно, хорошее, но если вы не гуру в японском, вам это не поможет.
Говорят, хоть сам не уверен, что Ши Го Рин - означает 4,6,колесо
> Говорят, хоть сам не уверен, что Ши Го Рин - означает 4,6,колесоХм... а он случайно не летчик? :)
5, а не 6.
> А язык у них - вообще английский!Пестишь - латынь это.
Латынь в американских университетах изучают, но разговаривают всё-таки на английском.
> Пестишь - латынь это.Вот прямо так уж for, begin, end, while, case, switch, void, ... - так уж прямо и латынь?
Вы не забывайте, что латынь туда притащили римляны, over 2000 лет назад.
Там жили такие же джамшуты, - ак слышаи, таки песа ли.
>> Пестишь - латынь это.
> Вот прямо так уж for, begin, end, while, case, switch, void, ...
> - так уж прямо и латынь?Но пробелы-то латынские!!
Вот вам латынь
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata....
"Разработка языка Python была начата в конце 1980-х годов сотрудником голландского института CWI Гвидо ван Россумом."
В отношении Python, америкосы в пролёте.
Тем временем на первых курсах в российских вузах, как и 25 лет назад, по-прежнему в 99% случаях преподают Pascal.
>Тем временем на первых курсах в российских вузах, как и 25 лет назад, по-прежнему в 99% случаях преподают Pascal.
>Тем временем на первых курсах в российских вузах, как и 15 лет назад, по-прежнему в 99% случаях преподают Excel.
мне на третьем преподавали.
У нас в 05'ом году на втором C# был. Ну и Excel, куда ж без него
> мне на третьем преподавали.Эксель?! Блин, а на первом курсе у вас там что, букварь начитывают?
На первом паскаль и делфи, на втором сишка и html/css, на третьем эксель и вижуал васик.
А к диплому, поди, нужно предоставить 10 листов А2, расчерченных в Пэйнте...
> А к диплому, поди, нужно предоставить 10 листов А2, расчерченных в Пэйнте...Правильно, CAD - для слабаков. Настоящие джедаи считают на калькуляторе, а потом рисуют в paint. В 3D сразу.
Excel преподают не студентам IT-специальностей.
> Excel преподают не студентам IT-специальностей.Бедняги, как же они без знания excel найдут работу в России?
Зря язвишь. Навыки и приёмы работы в excel чаще пригождаются на неИТ-специальностях чем условное программирование на паскале, васике и др. языках
Да, заучивание интерфейса проприетарной программы, которая раз в три года меняет интерфейс, - полезное занятие.
Если бы интерфейс некоммерческих программ не менялся каждые 2 месяца, учили бы их.
Какие изменения в этом месяце были в интерфейсе vim и TeX?
Сохранилась ли совметимость форматов?
> каждые 2 месяцаКакой ты скромный, написал бы сразу уж "каждые 2 часа"?
> Если бы интерфейс некоммерческих программ не менялся каждые 2 месяца, учили бы их.Странно, в мсо уже сменилось 2-3 интерфейса, а либра более-менее одинаково выглядит. По поводу чего половина народа свинтило с 2003 офиса на ооо/либру. Потому что переучивать весь персонал под бзики MS - себе дороже.
> 2003 офисаА что, с тех пор прошло больше двух месяцев? Блин, как быстро время летит...
Когда нас учили экселю, то обучение выглядело так: "Написал программу на фортране? А теперь повтори ее же на экселе. Не знаешь, где кнопочка или функция? Посмотри в справке". Т.е. обучать интерфейсу никто и не собирался. И я считаю, что это было очень наглядно и полезно.
А вот на следющем курсе дали "изучение интерфейса" ворда и эхселя. Вот это был бред абсолютный, бесились все.
А что Excel? Чисто декларативное функциональное программирование. Сразу понятное и сразу полезное.
>Excel
>функциональное программированиеПалишься.
>Сразу понятное и сразу полезное.
Он еще и Тьюринг-полный.
И безо всяких императивных VBA, чисто как табличка с формулами-зависимостями.> You can implement a TuringMachine as a one-dimensional CellularAutomaton, which can be implemented as a SufficientlyLarge spreadsheet with all cells except the first row filled with an appropriate calculation. The width of the spreadsheet is the length of available tape and the height of the spreadsheet is the maximum time available for the computation.
>http://c2.com/cgi/wiki?MicrosoftExcelProgrammingLanguageТак что вопрос, как всегда, не "что" (в данном случае - использовать в процессе обучения), а "кто" и "как".
> Он еще и Тьюринг-полный.Брейнфак тоже Тьюринг-полный, если что.
>> Он еще и Тьюринг-полный.
> Брейнфак тоже Тьюринг-полный, если что.Мы один месяц в универе брэнфачились.
> Мы один месяц в универе брэнфачились.А что за универ такой интересный, где брейнфак начитывают? И главное - зачем они это делают? Для отличников по брейнфаку - предлагаю опробовать SUBLEQ. Это еще интереснее :).
>И главное - зачем они это делают?чтоб дошло что язык имеет значение? :-D
> чтоб дошло что язык имеет значение? :-DНе хочу вас расстраивать, но у вас на любом ЯП будет получаться одно и то же.
>> чтоб дошло что язык имеет значение? :-D
> Не хочу вас расстраивать, но у вас на любом ЯП будет получаться
> одно и то же.имеешь в виду именно меня? или "такие как я" или еще?))) Вообще, спасибо, надеюсь что так и будет, если это одно и то же будет тем, что мне нужно.
> спасибо, надеюсь что так и будет, если это одно и то
> же будет тем, что мне нужно.Единственная проблема - качество этого кода (а также как следствие стабильность и безопасность оного, не говоря уж о скорости работы и потреблении ресурсов) будет мягко говоря не на высоте. В общем то единственная проблема. Правда ее достаточно для того чтобы обходить ваши программы за пушечный выстрел.
>> чтоб дошло что язык имеет значение? :-D
> Не хочу вас расстраивать, но у вас на любом ЯП будет получаться
> одно и то же.Многабукав?
> Многабукав?Да ладно вам, в слове "гoвнoкод" букв не очень много.
На этом его достоинства и заканчиваются.
> На этом его достоинства и заканчиваются.Да эксель как среда программирования тоже не блещет тысячями достоинств. Нет, конечно при большом желании можно и микроскопом гвозди забивать. Будет похоже на программирование в экселе.
Для непрограммистов - очень даже блещет.
Во всяком случае, альтернатив так и не взлетело пока.
> Для непрограммистов - очень даже блещет.А для нестроителей - микроскоп видимо очень полезный инструмент для забивания гвоздей? :)
> Во всяком случае, альтернатив так и не взлетело пока.
Непрограммисты как правило программированием не занимаются, просто по определению.
Чему же здесь аналогом микроскоп, разве мы обсуждаем Haskell в руках секретарши?
И чем же плохо когда непрограммисты самостоятельно делают в том же Excel вполне внятную таблицу, а то и несколько, умеющую себя пересчитать при изменении первичных данных? И чем это не программирование?
> Чему же здесь аналогом микроскоп,Непрограммисты vs нестроители, с столь же "удачным" выбором инструментария.
Ну так что же, если нестроители самостоятельно забьют в стену гвоздь, повесят шторы, переклеят обои, допустим? Это плохо? Звать строителей? Они боятся остаться без работы?
> Ну так что же, если нестроители самостоятельно забьют в стену гвоздь, повесят
> шторы, переклеят обои, допустим? Это плохо? Звать строителей? Они боятся остаться
> без работы?Нет, это нормально, но даже НеСтроитель как правило все-таки допирает взять в руки для забивания гвоздя настоящий молоток, а не микроскоп, не надувной музыкальный молоток и даже не отвертку. А наткнувшись на бетонную стену - быстро усваивает что нужен не то что молоток, а убедительный перфоратор, сравнимый с нормальными профессиональными инструментами. Если не хочется др@читься полдня над задачей которая за 5 минут решается. Написание *программ* на экселе - больше похоже на закручивание гвоздей отверткой.
Функционально-реактивное.
>>Тем временем на первых курсах в российских вузах, как и 25 лет назад, по-прежнему в 99% случаях преподают Pascal.
>>Тем временем на первых курсах в российских вузах, как и 15 лет назад, по-прежнему в 99% случаях преподают Excel.Excel мы в школе изучали классе в 7.
У нас были диктанты по менюшкам ворда и экселя.
Хе, у меня до сих пор лежит картонка с шестнадцатиричной таблицей умножнения, в 8 классе сам разлиновывал и заполнял.
> Хе, у меня до сих пор лежит картонка с шестнадцатиричной таблицей умножнения,
> в 8 классе сам разлиновывал и заполнял.Представляю себе как школьные училы делили на ноль увидев это :).
Вообще-то, именно учительница и сказала всем сделать такие таблички. И, знаете ли, полезная штука оказалась - в смысле формирования мышления.
> Вообще-то, именно учительница и сказала всем сделать такие таблички.Ого! Повезло с учителем. Или это была школа по типу какого-нибудь физмата.
Вы зря смеетесь. У нас не в самом плохом вузе (на IT-специальности ессно) находятся кадры, которые на 5-м (!) курсе не в состоянии нормально отчет в Ворде сделать. Так что Excel им будет явно полезен :)
Если эти же кадры способны вместо этого сделать отчет в TeX - проблема явно не в их способностях.
> Даже если не способны, к их способностям это отношения не имеет.Зато если этот тезис проинвертировать - получится интереснее. Если кто способен сделать отчет в TeX - он как правило будет далеко не идиoт и способен на многое. А вот с мышевозилой - это еще как повезет...
Если бы они приносили аккуратненький отчетик из TeX'а, вопросов бы к ним не возникало.
IT-специальность и отчет в Ворде... не понимаю, где тут связь?
Проблема в слове "отчет" или слове "Ворд"?
> Проблема в слове "отчет" или слове "Ворд"?проблема в учебном заведении, где нужные какие-то «отчёты в ворде».
> Вы зря смеетесь. У нас не в самом плохом вузе (на IT-специальности
> ессно) находятся кадры, которые на 5-м (!) курсе не в состоянии
> нормально отчет в Ворде сделать.я на четвёртом десятке лет не в состоянии отчёт в ворде сделать. и даже не планирую этому учиться.
10 класс, школа с уклоном в иностранные языки. Информатика. Половину учебника рассказывается как создать учетку на маилру. ЕГЭ форева.
Что не мешает занимать 1-ые места на разных олимпиадах и тд тпПлохому танцору ...
Олимпиадники - это единицы. А нужна массовость.
Кому нужна массовость? Что за странные требования? "Массовые" языки это javascript и php, что вы можете сказать о их качестве?
Если хотим, чтобы в России массово писали ПО, то учить студентов стоит C, C++, C#, Java, .NET.
> Если хотим, чтобы в России массово писали ПО, топокажите как приятно и увлекательно что-то программировать. Учителя не нужны.
>> Если хотим, чтобы в России массово писали ПО, то
> покажите как приятно и увлекательно что-то программировать. Учителя не нужны.ты точно уверен, что конечная цель — именно говнокод?
>>> Если хотим, чтобы в России массово писали ПО, то
>> покажите как приятно и увлекательно что-то программировать. Учителя не нужны.
> ты точно уверен, что конечная цель — именно говнокод?Щито поделать, десу?) Чтоб массово писали ПО и говнокод не увеличился - нереально.
так может, ну её, такую массовость тогда? ;-)
> так может, ну её, такую массовость тогда? ;-)можно и ну её)) Однако стоит помнить, что говнокод присутствует и там, где массовости нет ;)
>> так может, ну её, такую массовость тогда? ;-)
> можно и ну её)) Однако стоит помнить, что говнокод присутствует и там,
> где массовости нет ;)но однозначно меньше, чем там, где массовость. просто в силу объёмов кода.
>>> так может, ну её, такую массовость тогда? ;-)
>> можно и ну её)) Однако стоит помнить, что говнокод присутствует и там,
>> где массовости нет ;)
> но однозначно меньше, чем там, где массовость. просто в силу объёмов кода.Верно. Еще стоит помнить, что массовость, кроме негативного аспекта (говнокод) еще даст и положительный эффект, в виде хорошего кода и кодеров, хоть и в гораздо меньшей, разумеется, степени. Пусть даже 1000 к 1. Стоит это того или нет - неважно, всеравно никто из нас не собирается эту массовость воплощать :D
ну, это вообще вопрос философский: «стоит ли появление одного хорошего программиста возрастания количества говнокода в тысячу раз?» я бы ответил, что нет.
Как хорошо, что вам никто не задает такие вопросы.
> Как хорошо, что вам никто не задает такие вопросы.ты зачем с дерева спустился?
> ну, это вообще вопрос философский: «стоит ли появление одного хорошего программиста
> возрастания количества говнокода в тысячу раз?» я бы ответил, что нет.я бы тоже. Если б не пользовался трудами хороших программистов ;)
> я бы тоже. Если б не пользовался трудами хороших программистов ;)при лавинообразном увеличении количества говнокода труд хорошего программиста будет найти столь же сложно, как изумруд в помойке.
>> я бы тоже. Если б не пользовался трудами хороших программистов ;)
> при лавинообразном увеличении количества говнокода труд хорошего программиста будет найти
> столь же сложно, как изумруд в помойке.и тем не менее, изумруды на помойках _редко валяются. Может они есть, конечно, и их никто там искать не догадывается :D Но если хочешь изумруд - ты знаешь где его искать и на помойке не ищешь. Хочешь более менее лучшую на сегодняшний день систему - знаешь где искать. Возможно уже нашел, и общаешься с теми у кого похожие интересы, хотя возможно начинал с винды и когда начинал - даже не подозревал о том что есть лучше/хуже/и вообще критерии. Нет причин не доверять себе)
> ну, это вообще вопрос философский: «стоит ли появление одного хорошего программиста
> возрастания количества гoвнокода в тысячу раз?» я бы ответил, что нет.Скорее, "предотвращение глобального одeбиливания". Все-таки вреда от полных дeбилов слишком уж много. Так, в сумме. В общепланетарном масштабе. Не только в программировании. А развитие головного мозга все-таки несколько противодействует превращению в тyпyю ск@тину, умеющую только хaвать.
Но да, проблема с появлением кучи cpaни среди которой искать программы становится сложно - имеется.
ну вот похапистов — толпа. сколько из них развились, а сколько загаживают мир своим шлаком, даже не пытаясь превратиться в людей? «а чо, и так платят, гыгы!»
Ну а что, рыночные законы. Если кто готов платить - пусть кушают такое. Они обычно все-равно на заказ это кодят и тебе это рассматривать не придется.
> и тебе это рассматривать не придется.ещё как придётся: в сраных интернетах. как будто ты не видел «хипстеродизайна».
> ещё как придётся: в сраных интернетах. как будто ты не видел «хипстеродизайна».Так платить более хорошим програмерам они всяко не будут.
> Так платить более хорошим програмерам они всяко не будут.с чего ты это решил? человек заказывает сайт. он ничего не понимает в сайтостроительстве, и поэтому нанимает специалиста. если бы у человека было время и/или желание разбираться, то он бы не нанимал специалиста, а разобрался и сделал сам.
и вот тут уже наченается беда: вместо специалиста он нанимает похапэшника. именно потому, что не разбирается, а похапэшник запудривает мозги. то есть, похапэшники занимаются мошенничеством, выдавая себя за специалистов.
это как если бы я пришёл в клинику на операцию, а мне санитар начал рассказывать, что «эти хирурги за работу берут бешеные бабки, а всего-то дела — разрезать, вынуть, да зашить; я каждый день такое делаю, и всё нормально, никто не жалуется!» правда, делает он это в морге, но я-то не спец в медицине и хирургии, мне срочно аппендикс вырезать надо!
понятно, что я сам дурак в этом случае, но действия санитара как минимум непорядочны.
> с чего ты это решил? человек заказывает сайт. он ничего не понимает
> в сайтостроительстве, и поэтому нанимает специалиста.И его как правило дико давит жаба: как же так - 20 тыс? Вы же всего лишь за компьютером сидите?! Даже вагоны не разгружаете, etc! За что двадцатка то?!
Ну вот и получают столько сколько платят. Квалифицированный кадр не будет за двадцатку полмесяца землю рыть, выслушивая какой он медлительный. И вообще, гражданин, вам сложно чтоли вот тут переверстать, вон там шрифт исправить, пару скриптов дописать, дорисовать вон ту фигню и поддержать IE6, которым наш шеф-ретард пользуется, и в котором он проверяет как это выглядит? Что значит - денег за доработку? Вы что, охренели? Да за это 20 кусков - уже перебор?!
> если бы у человека было время и/или желание разбираться,
У клиентов веб-фломастеров такого желания нет, время как правило "надо еще вчера", а жаба удушает хуже угарного газа. Ну и получают по принципу "как заплачено, так и зафигачено". Это вполне честно вроде...
> и вот тут уже наченается беда: вместо специалиста он нанимает похапэшника.
...потому что никто кроме похапэшника не будет за двадцатку почти месяц попу рвать. Принцип "как заплачено так и зафигачено" во всей красе.
> именно потому, что не разбирается, а похапэшник запудривает мозги.
Да не, просто пэхэпэшник будет за двадцатку почти месяц возиться. А специалисты попрофессиональнее помашут факом, доходчиво объясняя что не негры на плантации и их время денег стоит. А платить по тарифам нормальных специалистов - готовы далеко не все.
> то есть, похапэшники занимаются мошенничеством, выдавая себя за специалистов.
Да никакого мошенничества, ловкость рук, баланс спроса и предложения и никакого обмана :).
> это в морге, но я-то не спец в медицине и хирургии,
> мне срочно аппендикс вырезать надо!Кое-что общее, конечно, есть, но если ты будешь давиться жабой так же как заказчики сайтов - таки есть шансы что твой аппендикс будут изучать именно в морге...
штука ещё и в том, что большая цена тоже не гарантирует качество.
> штука ещё и в том, что большая цена тоже не гарантирует качество.Зато жлобство заказчика и невменяемые требования - более-менее гарантируют что работать с ним будет только не сильно гордые субъекты, которым на выбор только вагоны разгружать.
> так может, ну её, такую массовость тогда? ;-)Вообще, поумнение населения - это хорошо. Зачем нам стада тyпых деградантов? А так мозг хоть немного развивается. Но, правда, немного. Зато +100 к ЧСВ добавляет, увы.
>Зачем нам стада тyпых деградантов?Чтобы их доить, че непонятного то?
Вот ты себя относишь к умным а сам в стойле и даёшь надой.
Так что всё по плану - продолжай жрать и срать на форумах :)
так паскаль весьма академичен, и в ооп версии тоже. В чём проблема то? Может при изучении программирования с регулярных выражений начинать?
Можно и с регулярных выражений.
Если в процессе изучить теорию автоматов, теорию формальных языков и классификацию формальных грамматик по Хомскому, откуда они выросли, внимательно проработать на семинарах работу Клини [1], которой руководствовался Томпсон.
Пользы будет значительно больше чем от вычисления факториала на Паскале.[1] Kleene, Stephen C. (1956). "Representation of Events in Nerve Nets and Finite Automata". In Shannon, Claude E.; McCarthy, John. Automata Studies. Princeton University Press. pp. 3–42.
> Пользы будет значительно больше чем от вычисления факториала на Паскале.Смотря что под пользой понимать. Для того чтобы насыпать корм рыбам по таймеру, запрограммив ардуину - настолько крЮтого знания теории автоматов совершенно не требуется.
Здесь вроде бы обсуждается высшее образование.
Для дрессировки насыпателей корма по таймеру достаточно ПТУ, максимум - техникума.
> Здесь вроде бы обсуждается высшее образование.А я думал - программирование.
> Для дрессировки насыпателей корма по таймеру достаточно ПТУ, максимум - техникума.
Так 99% задач к чему-то такому и сводится на самом деле.
Мы изучали паскаль, 3-е в intel, 2-е в ibm. Дело не как начнешь, а как закончишь.
> Тем временем на первых курсах в российских вузах, как и 25 лет
> назад, по-прежнему в 99% случаях преподают Pascal.Я Pascal не изучал. GW Basic и Fortran 77.
> Я Pascal не изучал. GW Basic и Fortran 77.И как ваши успехи по программированию теперь?
Вопрос закономерен.
Кисленько знаю (все слабо) ФрееПаскаль, Си, фасм/масм, очень прилично Питон+плюшки. С высказыванием ниже -- не согласен. Я радоинженер. Много можно найти радиоинженеров, которые шкодят хоть на бейсике. А совсем по хорошему, видел я выпускников ВУЗов с программистким профилем -- полных нулей. Я на их фоне смотрюсь выгодно. ))) fantom-lab.ya.ru Язык не важен, если знаний __нет__.
> Кисленько знаю (все слабо) ФрееПаскаль, Си, фасм/масм,На самом деле мой вопрос должен был звучать иначе. Вы понимаете как работают компьютеры? Например, из чего состоит микропроцессорная система, как это работает, чем текущие варианты отличаются от "классики", etc. Наверное это нормальный вопрос в сторону радиоинженера (хотя таковые бывают разные, возможно что я и не угадал, т.к. на чем именно вы специализируетесь я не знаю).
> очень прилично Питон+плюшки. С высказыванием ниже -- не согласен.
Хорошо бы еще указать путем цитирования, с каким именно. А то "ниже" - "всего" 30 страниц текста :\.
> Я радоинженер. Много можно найти радиоинженеров, которые шкодят хоть на бейсике.
Радиоинженеры бывают разные. Что за устройства вы разрабатываете, что при этом не требуется уметь программировать?
> ВУЗов с программистким профилем -- полных нулей.
Так получить в отечественных ВУЗах знания которые будут где-то востребованы и/или будут соответствовать текущему state of art отрасли - невозможно. Не учат там этому. В самом лучшем случае в нескольких ВУЗах могут сносно дать теорию по ряду направлений.
> Я на их фоне смотрюсь выгодно. ))) fantom-lab.ya.ru
Честно говоря не понял что именно на этом сайте преподносится как выгодное достижение, на фоне которого остальные блекнут.
P.S. кстати компания Яндекс приготовила своим пользователям подарок: "Друзья, этим летом мы закрываем Я.ру. Приносим вам свои извинения."
> Язык не важен, если знаний __нет__.
Вот я и пытаюсь понять: а какие знания у вас есть? Из упомянутого бложика я этого не понял.
Ох многа букафф, ниасилил. )))
Как работает компьютер , понимаю вполне сносно, имею представление о том, что такое спаривание команд, кеш, конвейер, ДМА и как работают регистры xmms0...xmms7. Как заставить работать ЦП в защищенном режиме понял, но из-за нехватки информации в свое время -- перепрограммировать контроллер прерываний не смог со всеми вытекающими.
Я заканчивал военный вуз (технические средства охраны режима госграницы). Цифровык устройства были, но закнчилось все на уровне ячеек памяти. Были "микропроцессорные системы", с курсовой на КР80ВМ80. На этом, пожалуй и все.
Сейчас работаю инженером по авт. системам диспетчерского управления в энергетике. На Github пилю свой проект помаленьку -- pyPC (virtual computer). Состояние зачаточное, но я не тороплюсь, зарплату мне никто не платит. )))
По работе программирование не надо совсем.
> Как заставить работать ЦП в защищенном режиме понял, но из-за нехватки
> информации в свое время -- перепрограммировать контроллер прерываний не смог со
> всеми вытекающими.ИМХО пойнт не в том чтобы зазубрить регистры или команды. А в том чтобы понять идею DMA и осознать что так можно нехило разгрузить проц (правда, это актуально для системщиков а не прикладников). Идею SIMD/MIMD, чтобы понять как это влияет на стиль программирования. Идею различных режимов процессора и прочее, чтобы понять как это работает (деление кернел-юзер прежде всего) и, например, почему частое переключение кернел-юзер - плохо. X86 имхо далеко не лучший для изучения подобных вещей: сложный и кривой, с кучей легаси.
> с курсовой на КР80ВМ80. На этом, пожалуй и все.
i8080 (с которого он дран) не так уж плох чтобы понять основы - он простой. А улучшения которые исторически приделывали - можно постепенно изучать по мере желания/необходимости.
> Сейчас работаю инженером по авт. системам диспетчерского управления в энергетике.
Я так подозреваю что текущий state of art цифровых систем вы не особо мониторите.
> На Github пилю свой проект помаленьку -- pyPC (virtual computer).
Мне из эмуляторов нравится фабрисовское творчество. Фабрис - профессионал, один из грандов отрасли. И поэтому умеет делать программы правильно. И если заметить, он сделал эмулятор на си чтобы применять всерьез, и на JS - поиграться совсем немного и забить, показав забавный фокус ALL-у, там где линух в браузере за вполне разумное время стартует и даже не очень тормозит.
Те эмуляторы которые на си - пошли и захватили мир. В виде qemu/KVM - KVM теперь у половины хостеров в почете. Кроме всего прочего, KVM обеспечивает скорость >90% от железяки в вычислительных задачах и при доступе к памяти. С I/O конечно похуже. Но все-таки довольно близко к железу по скорости при том что это VM с полной изоляцией от системы хоста. Там куча фич, куча оборудования, за годы и годы толпа народа это более-менее отладили и обезглючили (и то грабли случаются). Оно может уйму разных кульных вещей типа проброса девайсов (PCI, USB) с хоста в гуест. Но это серьезный проект, Фабрис и многие другие на это немало времени убабахали. Даже не потому что си, а потому что объем задачи за которую они схапались - огого. Фичность немеряная. Может даже какой-нибудь ARMовский исполняемый файл запустить на х86 системе. Понятно что в этом случае скорость просядет, и уже отнюдь не на несколько процентов. Однако вставить транслятору ARM -> x86 от Фабриса сможет не так уж много программистов на этой планете.
> Состояние зачаточное, но я не тороплюсь, зарплату мне никто не платит. )))
Проблема в общем то в том что для того чтобы сделать хороший эмулятор, который если не натянет Фабриса то по крайней мере покажет что-то сравнимое - надо полжизни положить. Иначе это будет игрушка, демонстрирующая печальный результат, плохо поддерживаемая, на которую скорее всего забьет автор, а остальные вообще не поймут зачем оно надо и проект тихо сойдет на нет. Если под PC понимается эмулятор х86 писюка. А писать эмуль на питоне - это заведомо тормознуть себя по скорости в фиг знает сколько раз. В эмуле чем короче путь по которому трансляция из исходной платформы в целевую - тем лучше (в KVM например большинство команд выполняется напрямую на системном проце, перехватываются только привилегированные команды, что и позволяет ему на чистом счете и доступе к памяти показывать более 90% от оригинала).
> По работе программирование не надо совсем.
И это заметно. Ну вот я например напнулся на какой-то бенч питона/паскаля/сей. И вижу там довольно странное нечто. Во первых я не понимаю что именно оно пыталось отбенчить. Во вторых - а зачем в тугом цикле на каждую итерацию дергать запрос времени (насколько я понял тамошнюю логику)? Это не только искажает результат до неузнаваемости, дерг "сколько времени" еще и может являться "тяжелым" вызовом, который потратит времени сравнимо со всем остальным. Не говоря о том что есть такие вещи как resolution таймера используемого системой/рантаймом как источник времени (точность таймера не бесконечна и весьма системозависима, и в часто дергаемом цикле это вообще-то может роялить).
Нормальные люди делают так: смотрят сколько времени до начала запуска алгоритма, гоняют алгоритм, а потом смотрят сколько времени в конце. Ну а время выполнения алгоритма - конечное время минус начальное. Если было много итераций - деленное на число итераций. Так работа со временем не портит результаты и намного меньше зависит от разрешения системного таймера и чего там еще.
Зубрить совершенно смысла нет. Я именно говорил про понимание принципов.
i8080 -- это азы, но к реальной жизни имеет уже весьма смутное представление, поэтому сейчас речь идёт только о 386+.
pyPC -- это исключительно химерный компьютер рождённый моей головой. Поэтому ни КВМ, ни ВиртуалБокс его никогда не запустят. В-общем, в этом вся затея. Трансляция в нативные команды на лету - это круто для меня, до такого вряд ли дорасту с вероятностью 95%.
Что касается скорости исполнения -- то я пользую cython (в модуле центрального процессора почти чистый Си с разметкой python). Так что скорость исполнения будь здоров.Что касается моих тестов -- замер времени либо по исполнению 5000 циклов, либо методом timeit. Разница в результатах - смешная. Так что, тест вполне объективен.
> i8080 -- это азы, но к реальной жизни имеет уже весьма смутное
> представление, поэтому сейчас речь идёт только о 386+.Да как сказать? Годы шли, а общие идеи в основе работы микропроцессоров никуда не делись. Развили хорошо. Но большинство улучшений - не такая уж новость, просто все и сразу было сложно сделать. Те кто владеет текущим state of art - обычно могут предвидеть развитие на годы вперед.
Пример того что я считаю профессионализмом электронщика: в эпоху первых пентиумов и PCI, один человек, посмотрев на USB, сказал что в будущем будут рулить скоростные последовательные шины с дифференциальным сигналом, похожие по смыслу. Хотя USB 1.1 смотрелся смешно на фоне, например, PCI. Годы шли. Появился PCI-E, SATA, USB3, HDMI, DisplayPort... И у всех них оказалось кое-что общее.
> pyPC -- это исключительно химерный компьютер рождённый моей головой. Поэтому ни КВМ,
> ни ВиртуалБокс его никогда не запустят. В-общем, в этом вся затея.Тот же QEMU - тоже изначально задуман как виртуальный компьютер, с виртуальной периферией. Просто теперь он "хорошо оптимизированный". Поэтому когда возможно - не то что транслируют, а просто выполняют большинство команд напрямую на системном проце (по сути это и называется KVM), обрабатывая только исключения (работу с железом, чего в юзермоде конечно же не положено) в гипервизоре (для чего требуется выносок в ядре хостовой системы). И даже решили что нафиг эмулировать реальные железки и регистры. Пусть ОС в гуесте знает что это - виртуализатор. И использует драйвер, который умеет сбагривать I/O на хост короткими и быстрыми путями. Это называется virtio. В результате оно разогналось до скоростей сравнимых с реальной железякой, перестав быть забавной игрушкой.
> Трансляция в нативные команды на лету - это круто для меня,
> до такого вряд ли дорасту с вероятностью 95%.Это один из немногих методов выполнить чужой код с вменяемой скоростью. Хотя для действительно приличной скорости все серьезные виртуализаторы выполняют большинство команд на системном проце напрямую и обманывают операционку, запущенную как user mode процесс, подтасовывая обработку исключений при привелигированных командах так, что kernel-mode код гуеста не замечает того что это user-mode, а не kernel-mode.
По поводу таких оптимизаций в серьезно настроенных виртуализаторах сдулись даже севые, но не оптимизированные в эти направления виртуализаторы по типу bochs. Они были неприемлимо тормозными, про них при удобном случае все забыли.
> будь здоров.
А это сколько процентов от производительности host? KVM может более 90% при счете и доступе к памяти, сохраняя все плюсы виртуализатора. Т.е. например пнутый в нем какой-нибудь "7z b" (бенчмарк в архиваторе 7zip) покажет процентов 90 того что он показывает на железке. Вот это уже интересно. Но это потребовало нехилой оптимизации и ряда трюков, в сумме энное количество народа пахало над доведением этого до кондиции несколько лет.
> Что касается моих тестов -- замер времени либо по исполнению 5000 циклов,
> либо методом timeit. Разница в результатах - смешная. Так что, тест
> вполне объективен.Не знаю что есть "методом timeit", но в целом часто дергать запросы "сколько времени?" в процессе бенчмарков в тугом цикле не следует, а если кто так делает - это не в его пользу говорит, т.к. показывает что человек полез бенчмаркать, не умея это делать и будучи не в курсе про resolution таймеров, оверхед от вызовов и прочем. Да и первый вопрос который возникает: что бенчмаркано и зачем? Какие-то реально существующие программы оптом выполняют подобный код? Нормальные бенчмарки или пытаются забенчмаркать какой-то общий аспект работы системы (например, "скорость доступа к памяти") или пытаются прогнать какой-то практически-значимый алгоритм (например, "сколько времени займет хеширование 10 мегабайтов с использованием sha-1?"). А по такому коду не понятно что являлось целью бенчмарка. Доказать всему миру что "питон не тормозит ну хоть где-то"?
>> i8080 -- это азы, но к реальной жизни имеет уже весьма смутное
>> представление, поэтому сейчас речь идёт только о 386+.
> Да как сказать? Годы шли, а общие идеи в основе работы микропроцессоров
> никуда не делись. Развили хорошо.Не вижу революции. Вычисления на GPU могли бы на них претендовать, но пока слишком мало кардинальнвх отличий. ИМХО, введение кеша, конвейера, страничной адресации и механизмов защиты -- это было последним существенным шагом, и не самым простым, как для реализации, так и понимания.
> Пример того что я считаю профессионализмом электронщика: в эпоху первых пентиумов и
> PCI, один человек, посмотрев на USB, сказал что в будущем будут
> рулить скоростные последовательные шины с дифференциальным сигналом, похожие по смыслу.) Я вообще не понимаю, зачем был сделан USB, когда был более чем работающий COM. Что мешало просто поднять частоту обмена? А протокол обмена, косящий под сетевые фреймы был известен уже очень давно под именем "Модбас" и ему подобных. Тысячи их. А крепление COM мне на порядок больше нравится, чем USB (ну, по крайней мере -- в производстве)
>> pyPC -- это исключительно химерный компьютер рождённый моей головой. Поэтому ни КВМ,
>> ни ВиртуалБокс его никогда не запустят. В-общем, в этом вся затея.
> Пусть ОС в гуесте
> знает что это - виртуализатор. И использует драйвер, который умеет сбагривать
> I/O на хост короткими и быстрыми путями. Это называется virtio. В
> результате оно разогналось до скоростей сравнимых с реальной железякой, перестав быть
> забавной игрушкой.Да я в курсе как виртуализация построена. У самого Ulteo и coLinux постоянно вертятся.
Идея моего виртуального писюка именно в том, чтобы не иметь ничего общего с реальным писюком. Вопрос быстродействия важен, но он не дороже информационной безопасности.
> По поводу таких оптимизаций в серьезно настроенных виртуализаторах сдулись даже севые,
> но не оптимизированные в эти направления виртуализаторы по типу bochs. Они
> были неприемлимо тормозными, про них при удобном случае все забыли.Бочка для разрабов и параноиков. Не для виртуализации, имхо задачи стоят несколько другие.
>> будь здоров.
> А это сколько процентов от производительности host? KVM может более 90% при
> счете и доступе к памяти, сохраняя все плюсы виртуализатора.От производительности host машина будет давать в лучшем случае 25%. Но дело не в производительности. Мне и 200 млн. оп. на одном ядре хватит. Цель не стоит сделать повтор того ,что уже есть. Смысл? Цель стоит создать реализацию ПК, который будет заведомо безопасен, изолироваться от возможного большого брата и иметь возможность переносить системы с оси на ось, с ЦП на ЦП. Python такую возможность даёт непосредственно. Си, Паскаль, ассемблер -- заставят посуетиться чуть больше, или намного больше.
> Не знаю что есть "методом timeit", но в целом часто дергать запросы
> "сколько времени?"+0,5%
> в процессе бенчмарков в тугом цикле не следует, а
>Да и первый вопрос который возникает: что бенчмаркано и зачем?
> Какие-то реально существующие программы оптом выполняют подобный код? Нормальные бенчмарки
> или пытаются забенчмаркать какой-то общий аспект работы системы (например, "скорость доступа
> к памяти") или пытаются прогнать какой-то практически-значимый алгоритм (например, "сколько
> времени займет хеширование 10 мегабайтов с использованием sha-1?"). А по такому
> коду не понятно что являлось целью бенчмарка. Доказать всему миру что
> "питон не тормозит ну хоть где-то"?Первоначально идея была поюзать во FreePascal стандартную либу mmx. Для этого надо было включить парочку опций компилятора. После нескольких отчаянных попыток из официального руководства, дебаггера и нескольких часов времени понял, что реально юнит сделан криво, и абсолютно никакого прироста производительности нет. Я решил посмотреть как это сделано в других ЯП. В Си есть (по ассемблерному листингу) небольшая оптимизации по передаче параметров и работе со стеком в ходе вычислений. Почему Visual Bsic 6 пилит наравне с Си через рантайм, а cython уделал чистый Си я не разбирался, но могу предположить, что в случае VB6 идёт предварительная оптимизация вызовов (может трансляция в .NET по тихому?), а в случае с cython более удачные заготовки использованы для замещения python-кода + какие-то оптимизирующие ключи, о которых я не знаю?...
В любом случае, сравнивать sha-1, i/o и т.п. -- смысла нет. python не проигрывает Си в таких вещах. Просто не может. Т. к. юзает компиленные сишные модули. То же самое касается и системных обращений -- они зависят от системы и в других моментах такие же тонкости.
В итоге что остаётся тестировать?Кстати! Как-то писал zip-архиватор на python+cython. Таки на упаковке "Василия Тёркина" при (я надеюсь) одинаковом исходном алгоритма моя тулза паковала сильнее на 3...7% и быстрее почти вдвое, чем 7-zip!!! Правда памяти хавал раза в 1,5...2 раза больше.
> Не вижу революции. Вычисления на GPU могли бы на них претендовать, но
> пока слишком мало кардинальнвх отличий.GPU такие же процессоры как и остальные. Просто специфично оптимизированные. Так что это не революция, а "не прошло и двух декад, как люди наконец стали отпускать ручник". Надо же, какая новость: пачка простых но многочисленных ALUшек может не только графику долбить, но и с рядом иных алгоритмов неплохо справляется.
> ИМХО, введение кеша, конвейера, страничной адресации
> и механизмов защиты -- это было последним существенным шагом,Это всего лишь очередные улучшения. В глобальном смысле я склонен выделять как улучшение переход от 1-задачной, всем-можно-все модели к делению на "кернел" и "юзер", с арбитрированием потенциально опасных операций "кернелом". Это кроме всего прочего здорово повысило надежность систем (теперь сбойная программа не валит всю систему) и позволила делать многозадачные и многопользовательские системы с разделением прав между пользователями, без явной возможности Васе подкладывать свинью Пете только потому что это одна и та же машина. В какой-то такой момент микропроцессоры догнали большие машины по всем пунктам.
> ) Я вообще не понимаю, зачем был сделан USB, когда был более
> чем работающий COM.Там целая куча проблем!
1) USB - это сеть. И позволяет мультиплексировать данные для кучи устройств в одном проводе. Его можно разветвить хабами. До 127 устройств на шину. Попробуйте так с COM :P.
2) COM порт использует очень дурной формат сигнала - один провод относительно GND и с дурными 2-полярными уровнями из эпохи педально-релейой логики. Это накладывает неиллюзорные ограничения на соотношение длина vs скорость. У USB намного более удачная технологическая база была заложена - дифференциальная шина с относительно небольшим размахом сигнала. Поэтому они получили свои 12 Мбитов на 5 метров в первой версии вообще не напрягаясь. Ибо это для такой шины - вообще халява.
3) У USB сигнал обладает свойствами самосинхронизации, в него встроен clock recovery, в случае ошибок пакеты перепосылаются. В UART всего этого нет. Можно сделать самому до некоторой степени, но геморно и неуниверсально.
4) USB подразумевает некие стандартизированные классы устройств, так что система не знает как работать с "вот этой клавиатурой". Она видит - "некое HID устройство". Устройство шлет данные в оговоренном формате, его подхватывает стандартный драйвер этого типа устройств.
5) COM порт - соединение точка-точка, а не шина/сеть.> Что мешало просто поднять частоту обмена?
Даже с этим грабли: вы не сможете с высокой скоростью вызывать изменения относительно высоковольтного сигнала в мало-мальски длинном кабеле. Емкость кабеля надо перетянуть, знаете ли. По этой причине скоростные дифференциальные шины используют относительно небольшой размах сигнала, а для сохранения помехоустойчивости используется тот факт что внешняя помеха наводится на оба провода более-менее симметрично, так что если смотреть только на разницу уровней, а не абсолютную величину - помехи становятся до балды. Но это еще не все. Чтобы не перезаряжать весь кабель, используются "протоколы с нулевой постоянной составляющей". При этом до отправки битов в линию применяется специфичное кодирование, нацеленное на то чтобы не было длинных непрерывных сегментов с одинаковым уровнем сигнаола. Иначе кабель зарядится до вон того уровня - и удачи потом его перетянуть в нужное состояние, со всей его емкостью по всей длине.
> А протокол обмена, косящий под сетевые фреймы был известен уже очень давно под
> именем "Модбас" и ему подобных.Это далеко не чистый компорт который RS-232. Если уж рассматривать попытки разгона UART-образных, RS-485 через тривиальный конвертер ("глупый" транслятор уровней) может до десятков мегабитов, на относительно приличные дистанции. Но и это - тоже дифференциальная шина, с небольшим размахом сигнала. USB до кучи сделали сеть частью стандарта. Дурно, но лучше чем было до них.
> Тысячи их. А крепление COM мне на порядок больше нравится,
> чем USB (ну, по крайней мере -- в производстве)Только разъемом зашибить можно и (EPIC FAIL!) в стандарте 232 на разъеме нет питалова. RS232 - морально устаревший протокол из эпохи черно-зеленых терминалов и телетайпов с педально-релейной логикой.
А вообще странно что я это электронищику объясняю. Вы и сами должны знать чем дифференциальные линии лучше для передачи сигналов. Это очень древняя техника, описанная еще в букварях конца 70-х прошлого века.
> Да я в курсе как виртуализация построена. У самого Ulteo и coLinux
> постоянно вертятся.Ну вот я и пытаюсь намекнуть что ваш виртуализатор на фоне существующих не будет чрезмерно востребованным и перспективным.
> Идея моего виртуального писюка именно в том, чтобы не иметь ничего общего
> с реальным писюком.Ну ок, я могу запустить в таком случае qemu который запустит мне ARMовый бинарь. ARMовая VM - явно не похожа на писюк под ней.
> Вопрос быстродействия важен, но он не дороже информационной безопасности.
Тезис о том что какая-то самопальная программа (при том довольно сложная) обладает сколь-нибудь хорошей безопасностью - далеко не очевидный. А какие аргументы в пользу этого тезиса? Ну вот D.J. Berstein может выдвинуть тезис почему его программы - безопасные (при том что на си). И внятно обосновать. И даже объявив премию в килобакс за взлом "для проверки" - не разориться на выплатах.
> Бочка для разрабов и параноиков.
Среди питонистов нормальных разработчиков вообще полтора человека. А остальные такого кода накоммитят что про безопасность можно будет навсегда забыть. Ибо если человеки о ней не думают в процессе кодинга - там будет уйма разных глупых плюх.
С точки зрения параноика - использовать программу на питоне (сразу подозрения насчет квалификации автора), довольно сложную и при том непопулярную - звучит как заявка на залет. Потому что если какому-нибудь АНБ станет надо - они с их ресурсами баги там как-нибудь найдут. А вот остальным они не скажут. А в силу параметров - остальных будет не сильно то и много. ИМХО очень спорный тезис получается.
> Не для виртуализации, имхо задачи стоят несколько другие.
Цель существования виртуализации - получить разделение близкое по качеству к разным физическим машинам при экономии на этих самых физических машинах. У хостингов и прочих достаточно высокие требования к изоляции - клиенты не должны иметь возможность гадить друг другу, иначе, если будут массовые взломы по линии виртуализатора - саппорту вынесут мозг, а репутация компании упадет ниже плинтуса. И да, хакеры всерьез хотят ресурсы - если где-то есть лазейка, ждите стайки автоматических ботов. Они придут и заберут дармовой ресурс.
> От производительности host машина будет давать в лучшем случае 25%.
Тогда это малоинтересно в плане практического использования в большинстве случаев. Если мне приемлима такая потеря скорости - можно qemu эмулирующий совсем иную архитектуру запустить. А при настоящей паранойе - вложить парочку напрочь разных друг в друга. Пусть MIPS транслируется в powerPC, а тот в x86_64, например. В KVMной виртуалке.
Мое отличие от вас? Я это соберу за 10 минут, из существующего софта, с результатом не хуже и еще вопрос у кого безопасность будет лучше, ибо qemu эксплуатирует толпа народа.
> Цель стоит создать реализацию ПК, который будет заведомо безопасен,
И что гарантирует что он "заведомо безопасен"? И на основании чего? Ну, кроме самоуверенности характерной для питонистов - есть какие-то более рациональные и научные обоснования? Типа того что у DJB, например?
> изолироваться от возможного большого брата
Guest не может изолироваться от хоста. Host может делать с guest все что пожелает. Если скажем BMC (или иной DMA-capable device, например, сетевка или там кто еще) может используя DMA читать и писать ВСЮ СИСТЕМНУЮ ПАМЯТЬ - попробуйте от него спрятаться. А ваша VM что, в какой-то другой памяти, чтоли? Можно пропатчить тихой сапой софт прямо в виртуалке, даже не очень парясь виртуалка это или что еще. Ну разве что это какая-то экзотичная архитектура будет... и то - comodohacker свел счеты с экзотичной VM от RSA, помнится. Так что как видим - если хаксору сильно хочется - он справится даже с экзотичной фиговиной. Другое дело что таких хакеров полтора человека на всю планету и заслужить их внимание надо еще суметь.
> и иметь возможность переносить системы с оси на ось, с ЦП на ЦП.
> Python такую возможность даёт непосредственно. Си, Паскаль,
> ассемблер -- заставят посуетиться чуть больше, или намного больше.Если у программера руки из правильного места, сишный код одинаково работает что в вон том микроконтроллере размером с тетрадную клеточку, что на вон том 64-битном шкафе. Си как раз может быть достаточно портабелен, особенно чистая математика, писаная более-менее пряморуким субъектом. Как пример - tweetnacl вполне себе работает и на микроконтроллере размером с тетрадную клеточку, и на большом 64-битном шкафе с серверами.
> +0,5%
Весьма и весьма системозависимо. Деталей не помню но в каких-то системах запрос времени был очень тормозной операцией. И понимание подобных грабель и превентивное парирование даже самой минимальной возможности наступить на проблемы - это то что и отличает специалиста от скрипткидизов. Программы от кидизов неиллюзорно лажают при малейшем изменении параметров системы, рантайма и внешних условий. Программы от специалистов - просто работают. Если спец хороший - см. выше что получается с тем же си.
> Первоначально идея была поюзать во FreePascal стандартную либу mmx.
Не очень понятна суть этой идеи. Какую самоценность несет использование "стандартной либы mmx" само по себе? Сам по себе MMX/SSE вообще дает выигрыш далеко не на всех алгоритмах и актуален в основном в мультимедийных данных, некоторых видах криптографии, некоторых научных вычислениях, обсчете вычисляемой графики и еще некоторых случаях. Далеко не любая программа сильно выигрывает от SIMD - очень зависит от того насколько ее логика ложится на идею SIMD.
> Для этого надо было включить парочку опций компилятора.
А например тот же си в случае х86_64 SSE может использовать даже на полном автомате, просто потому что он гарантированно есть. Но если посмотреть на бенчи, выигрывают от этого только некоторые программы.
> В Си есть (по ассемблерному листингу) небольшая оптимизации по передаче параметров
В х86_64 в плане передачи параметров все вообще лучше чем у х86, например - там можно пропихнуть параметры в регистрах, часть регистров - временный счет, часть - результат. Так в лучшем случае можно сэкономить на push/pop в стек, если по регистрам умещается. А оптимизация того же gcc зависит от флагов. И кстати супер-дупер оптимизация иногда может играть дурную шутку. Я тут показывал как-то arisu как LZ4, которому закрутили флаги оптимизации посильнее ... просел по скорости, хотя по логике вещей вроде должно быть наоборот :)
> вычислений. Почему Visual Bsic 6 пилит наравне с Си через рантайм,
> а cython уделал чистый Си я не разбирался, но могу предположить,
> что в случае VB6 идёт предварительная оптимизация вызовов (может трансляция в
> .NET по тихому?), а в случае с cython более удачные заготовки
> использованы для замещения python-кода + какие-то оптимизирующие ключи, о которых я
> не знаю?...Честно говоря - больше всего это похоже на кривой/нереалистичный бенчмарк, имхо.
> В любом случае, сравнивать sha-1, i/o и т.п. -- смысла нет. python
> не проигрывает Си в таких вещах. Просто не может.Кто вам это сказал? Там как раз каждый байт в тугом цикле может быть на счету и сильно умный высокоуровневый рантайм может все изгадить в два счета, просадив тугой цикл в разы.
> Т. к. юзает компиленные сишные модули.
...писаные на си? А тогда с какого баяна это считается заслугой ПИТОНА? Это заслуга сей по логике вещей получается ;). Ну вот все и пользуются криптографическими либами, либами сжатия/распаковки, обработки изображений, ... на си.
> В итоге что остаётся тестировать?
Ну да, если тактично удрапать от тестирования сколь-нибудь сложных алгоритмов, чувствительных к скорости - тормозить нечему. Какой-нибудь UI 99% ждет юзера и при этом вообще не так уж принципиально на чем он его ждать будет. Проблема будет в том что в остальном 1% юзер может исходить на г-но, когда он ждет машину в разы дольше чем мог бы.
> Кстати! Как-то писал zip-архиватор на python+cython. Таки на упаковке "Василия Тёркина"
> при (я надеюсь) одинаковом исходном алгоритма моя тулза паковала сильнее на
> 3...7% и быстрее почти вдвое, чем 7-zip!!! Правда памяти хавал раза
> в 1,5...2 раза больше.Я думаю что секрет тут в том что zip как формат уже давно мало кому интересен. Как известно, есть бесконечное количество способов сгенерить поток в том или ином формате, при том способы отличаются и по скорости и по эффективности. И тут вопрос восходит к алгоритму. А кто сказал что тот же алгоритм на си будет медленнее питона, например? А вообще нынче тем кому надо скорость - есть LZ4 и LZO. Хотите побить их по скорости? Ну... попробуйте. LZ4 на декомпрессии на моей системе до гигабайта в секунду разгоняется. Хотите посмотреть что вам сделает супер-пупер рантайм в тугом декомпрессионном цикле, где любая лажа сажает скорость на 30-50%? А кому надо сильное сжатие при хорошей скорости декомпрессии - есть lzma. И там кстати скорость сжатия тех или иных данных восходит к выбору алгоритма match finder'а. И сколь-нибудь честно сравнивать только одинаковые алгоритмы. А то разные match finder-ы для LZ разные сами по себе, независимо от того на чем их накодили - на уровне алгоритмики.
(почти оффтоп)
--------
pyPC пилю по нескольким причинам:
1. Неасилил IBM PC (качество и количество документации/железяк/ос -- в сумме очень мало и довольно плохо).
2. Я и без Сноудена знал что закладки делятся на две категории: аппаратные и софтовые.
3. Переносимая реализация, которая известна мне досконально, что хочу, то и прикручиваю.
> 1. Неасилил IBM PC (качество и количество документации/железяк/ос -- в сумме очень
> мало и довольно плохо).Там одни только спеки на чипсет - сотни страниц. На процы - как-то так же. Периферия нынче не лучше. Так что вы или будете делать упрощенный схематичный макет, как другие виртуализаторы (которые постепенно заменяют виртуальные железки вообще на быстрые и простые интерфейсы хост-виртуалка с поддержкой дровами в guest), или опупеете это программить. Кстати qemu реализовал не совсем архаичное железо даже. Но и не распоследнее новье.
> 2. Я и без Сноудена знал что закладки делятся на две категории:
> аппаратные и софтовые.Мы тоже в курсе. И что интересно, если некто может поиметь host, поимение виртуалки с guest лишь вопрос времени и желания. Хост может сделать с виртуалкой все что сочтет нужным. Виртуализатор делает это несколько менее удобным, но отнюдь не невозможным.
> 3. Переносимая реализация, которая известна мне досконально, что хочу, то и прикручиваю.
Боюсь что в таком виде оно будет ограниченным по возможностям и тормозным нечто, которое и близко не конкурент серьезным виртуализаторам. Сколько народа захочет такими программами пользоваться - несложно прикинуть.
>> 1. Неасилил IBM PC (качество и количество документации/железяк/ос -- в сумме очень
>> мало и довольно плохо).
> Там одни только спеки на чипсет - сотни страниц. На процы -
> как-то так же. Периферия нынче не лучше. Так что вы или
> будете делать упрощенный схематичный макет, как другие виртуализаторыНе буду. Моя виртуалка заведомо несовместима с существующим железом - это следствие цели.
>> 2. Я и без Сноудена знал что закладки делятся на две категории:
>> аппаратные и софтовые.
> Мы тоже в курсе. И что интересно, если некто может поиметь host,
> поимение виртуалки с guest лишь вопрос времени и желания. Хост может
> сделать с виртуалкой все что сочтет нужным. Виртуализатор делает это несколько
> менее удобным, но отнюдь не невозможным.Из-за несовместимой модели железа (и значит софта) -- поиметь будет крайне сложно. Разве что -- уронить сам сервер виртуальной машины.
>> 3. Переносимая реализация, которая известна мне досконально, что хочу, то и прикручиваю.
> Боюсь что в таком виде оно будет ограниченным по возможностям и тормозным
> нечто, которое и близко не конкурент серьезным виртуализаторам. Сколько народа захочет
> такими программами пользоваться - несложно прикинуть.Эта виртуалка не для бенчмейкеров. А для параноиков. )))
> Не буду. Моя виртуалка заведомо несовместима с существующим железомТогда не понятно как на ней софт вообще будет работать.
> Из-за несовместимой модели железа (и значит софта) -- поиметь будет крайне сложно.
С чего бы вдруг? Если вы вдруг думаете что хакеры - лози, не способные разобраться в плюс-минус еще одной системе команд процессора (пусть даже виртуального) - это ошибочное мнение. См. comodohacker vs DigiNotar. Он там вполне себе распетрушил какую-то нестандартную хрень от RSA.
> Разве что -- уронить сам сервер виртуальной машины.
Имея доступ к серверу который выполняет VM, можно влиять на выполнение VM произвольным образом. При том это достаточно просто - обычный патчинг кода или данных, возможно даже прямо на лету.
> Эта виртуалка не для бенчмейкеров. А для параноиков. )))
Тогда как один из таковых спрашиваю - на чем основано убеждение что этот софт более защищен чем остальные VM?
>> 1. Неасилил IBM PC (качество и количество документации/железяк/ос -- в сумме очень
>> мало и довольно плохо).
> Там одни только спеки на чипсет - сотни страниц. На процы -....
def офтоп():
'''
Брат Аноним, поясни почему чем больше пишешь -- тем больше минусов.
У тебя -- over -9000?...
Хабраэффект?
'''
>[оверквотинг удален]
>>> мало и довольно плохо).
>> Там одни только спеки на чипсет - сотни страниц. На процы -
> ....
> def офтоп():
> '''
> Брат Аноним, поясни почему чем больше пишешь --
> тем больше минусов.
> У тебя -- over -9000?...
> Хабраэффект?
> '''Забей на минусы, в отличие от хабратуалета, здесь они ничего не значат.
> Брат Аноним, поясни почему чем больше пишешь --
> тем больше минусов.Открою страшную тайну: это потому что чем больше пишешь, тем меньше аудитория поддерживает такую точку зрения, если она построена на песке. Вот Капитанов Очевидностей на опеннете - навалом.
И правильно. Учить питону - превращать человека не в программиста, а в морального урода.
Это почему же? Честно, интересно очень.
> Это почему же? Честно, интересно очень.Потому что
1) Low entry barrier, но позволяет сделать что-то шевелящееся, что дает +1000 к ЧСВ.
2) Эти фаготы полагают что переписывать работающую и отлаженную программу раз в полгода, когда авторам ЯП шлея под хвост попала - это как бы нормально.
3) Только моральный урод согласится чтобы окружение его ставило в стойло по гестаповски, на уровне синтаксиса.
> 3) Только моральный урод согласится чтобы окружение его ставило в стойло по
> гестаповски, на уровне синтаксиса.То есть только LISP, только хардкор?
> То есть только LISP, только хардкор?Да ну его, этот лисп. Там на все и вся один вид скобочек, так что программы получаются очень улыбчивые )))))))). Но вот читать их геморно даже с подсветкой синтаксиса - десяток одинаковых скобок рядом - это злобно.
Ну замените их на что-нибудь. Двацати строк препроцессора должно хватить с избытком.
> Ну замените их на что-нибудь. Двацати строк препроцессора должно хватить с избытком.Спорут нет, бывает и так... http://img0.joyreactor.cc/pics/post/программирование-быдлокод-1360803.png
> Тем временем на первых курсах в российских вузах, как и 25 лет
> назад, по-прежнему в 99% случаях преподают Pascal.И правильно делают. Лучше несколько "самых умных" студентов семестр потеряют, чем потерять весь поток.
Паскаль для задачи изучения алгоритмов более чем удачен, независимо от того, будет ли кто-нибудь его использовать или нет. И именно для введения в алгоритмизацию Паскаль и используется.
А вот с Питоном - наверняка первый месяц борются только с тем, чтобы студенты правильно отступы ставили. А до алгоритмов дело за семестр вообще не доходит. Да и не нужны они там - всё уже готовое встроено.
> уже готовое встроено.И в результате получаются кадры которые не могут написать свой base64-декодер, пля. Если вдруг рантайм чего-то не умеет - "ЗАДАЧА НЕРЕШАЕМА!"
>> уже готовое встроено.
> И в результате получаются кадры которые не могут написать свой base64-декодер, пля.
> Если вдруг рантайм чего-то не умеет - "ЗАДАЧА НЕРЕШАЕМА!"Если нужно будет - сможет программист, никуда не денется. Другое дело что всё решится быстрее, примерно так: тут нет 64 декодера, ага. Где есть? Ага, а документация какая? Стоит того? Да? Ок. Нет? Нах этот язык, берём другой, где нужное нам - есть.
> есть? Ага, а документация какая? Стоит того? Да? Ок. Нет? Нах
> этот язык, берём другой, где нужное нам - есть.Скрипткидиз во весь рост. А теперь такой финт ушами: входной поток может потенциально быть битым и в какой-то момент там может быть нарушение формата данных. Надо декодировать сколько получилось и отдать это + сообщить позицию ошибки в входном потоке.
Понимаешь, на стандартный случай сишник возьмет либу не хуже чем питонист. А вот на такой элементари почему-то обделывается почти любой жабист/питонист/рубист/дотнетчик/... - растопыривать пальцы про лямбда функции можем, а битики потасовать, достаточно примитивным образом - почему-то облом. Ведь рантайм же не умеет это именно так как надо было.
>Скрипткидиз во весь рост. А теперь такой финт ушами: входной поток может потенциально быть битым и в какой-то момент там может быть нарушение формата данных. Надо декодировать сколько получилось и отдать это + сообщить позицию ошибки в входном потоке.погуглю проблему и напишу, вообще без разницы на каком языке.
мы друг друга не совсем поняли, я конкретно вот о чём: если есть библиотека, а документация и реализация нареканий не вызывает - бессмысленно писать еще один плеер^W^W одну base64 библиотеку. Python не препятствует обучению, так как ты не только можешь написать свою реализацию, но еще и поглядеть как оно в "каноническом варианте" не отходя от кассы. А уж обработать какую-то ошибку - проще простого всё описано в документации, в том числе список исколючений на многие случаи жизни. Если уж проблема неординарная, и на низкоуровневом языке решение проскочит в этих наших интернетах, то переписать его на ЯВУ проблемы не составит.
> погуглю проблему и напишу, вообще без разницы на каком языке.Ты думать не умеешь, так что если вдруг готовое решение не нагуглится (а для таких вещей - может и не нагуглиться) - "задача нерешаема".
> мы друг друга не совсем поняли, я конкретно вот о чём: если
> есть библиотека, а документация и реализация нареканий не вызывает - бессмысленно
> писать еще один плеер^W^W одну base64 библиотеку.Ну а я привел случай когда стандартные реализации под задачу не подходят. Большинство кидди-образных при этом делает козью морду и объявляет что задача нерешаема.
> Python не препятствует обучению,
Сам по себе он, конечно, не препятствует, но "создайте систему которой может пользоваться даже дypaк, и только дypaк захочет ей пользоваться". Вот глядя на питонистов я понимаю что в этом высказывании есть пойнт. Найти питониста с более-менее нормальными фундаментальными знаниями по программированию + пониманием процесса разработки ПО? Это фантастика. На этом пишут всякие кидизы, гонящие как на пожар, не умеющие думать и не знающие базовых вещей. Получается понятно чего. Жуткое, тормозное, глюкавое и проблемное нечто. Единственным плюсом которого относительно остального софта обычно является "зато на питоне!!!111".
> так как ты не только можешь написать свою реализацию, но еще
> и поглядеть как оно в "каноническом варианте" не отходя от кассы.Я это могу в любом случае - предпочитаю открытое ПО.
> А уж обработать какую-то ошибку - проще простого всё описано в
> документации, в том числе список исколючений на многие случаи жизни.Остается только вопрос в том насколько такой нестандартный вариант вообще предусмотрен разработчиками и насколько их действия при такой ошибке - похожи на то что хотелось. Это вообще не факт.
> Если уж проблема неординарная, и на низкоуровневом языке решение проскочит в
> этих наших интернетах, то переписать его на ЯВУ проблемы не составит.Весьма громкий тезис. На низкоуровневом ЯП можно сходить по фиксированному адресу 0x20000000 и выполнить оттуда код, даже не зная что это. На высокоуровневом ЯП с подобным маневром будет жесточайшее обломинго.
...и правильно делают! Паскаль - он и "словоблудный" (чтобы новички не терялись в значениях "крючочков"), и технически строгий, статичный, т.е. даёт какое-то дополнительное промежуточное представление об аппаратуре. Это дисциплинирует мышление, чтобы люди не зарывались в процессе построения воздушных пейстоновских архитектур - всему есть своя цена.
> Тем временем на первых курсах в российских вузах, как и 25 лет назад,
> по-прежнему в 99% случаях преподают Pascal.А что паскаль? Он для обучения как раз хорош. Паскаль плохому не научит. А гвидобэйсик и есть гвидобэйсик.
И что в этом плохого?
Ага, Паскаль и Бейсик тоже были в топе у школьников/студентов много лет назад. Их сейчас кто-нибудь помнит?
Паскаль всё так же преподают. Хотя неясно, в чём проблема изучать Си, если даже школьники с этим справляются.
Считается что большинство людей по какой-то причине неспособны понять концепцию указателей.
Большинству людей это нафиг не нужно. Также как и высшая математика, физика и пр. науки в том объёме в котором их преподают. И проверка остаточных знаний это ярко показывает.
> Большинству людей это нафиг не нужно. Также как и высшая математика, физика
> и пр. науки в том объёме в котором их преподают. И
> проверка остаточных знаний это ярко показывает.Тех, кому это не нужно - гнать пропитанными тряпками из профессии.
Как и само это большинство людей.>Foxconn намерена заменить своих сотрудников роботами Foxbot
>http://www.ixbt.com/news/hard/index.shtml?18/10/27
> Как и само это большинство людей.Ну так участь у биороботов такая.
> Считается что большинство людей по какой-то причине неспособны понять концепцию указателей.Понять концепцию указателей не сложнее чем понять концепцию индекса в массиве. Память - тоже массив, а указатель - индекс в нем. Просто это суперглобальный массив, который содержит в себе все остальное. Чего там понимать то?
Вы у тех кто не понимает спросите.А объяснение ваше на самом деле очень сложное, вот то ли дело моанада - просто моноид в категории эндофункторов.
> Вы у тех кто не понимает спросите.Боюсь что при таком уровне понимания у них просто проблемы с логическим мышлением и единственное что им следует программировать - метлу.
> А объяснение ваше на самом деле очень сложное,
Чего там сложного? Вложенность одной сущности в другую - обычное дело в программировании, без осознания таких базовых вещей в программировании вообще дальше hello world не уедешь.
> Боюсь что при таком уровне понимания у них просто проблемы с логическим
> мышлением и единственное что им следует программировать - метлу.Разумеется, нет. Если бы всё было так просто, "проблемы указателей" не возникло бы как таковой.
Эти люди нормально пишут на разных языках, а вот именно указатели вызывают у них ступор.> Чего там сложного?
А чего сложного в определении монады?
Для того чтобы чем-то пользоваться, нужно в первую очередь интуитивное понимание, определения мало помогают.
> Разумеется, нет. Если бы всё было так просто, "проблемы указателей" не возникло
> бы как таковой.Еще раз, если некто не может понять массивы и вложенность - какой из них программист, а?
> интуитивное понимание, определения мало помогают.
"Возьми третий стакан со второй полочки из шкафа". Вполне себе адресация массива и вложенность.
Индексацию массива и вложенность (тех же массивов) он понимают.
Не понимают они - указатели.
> Не понимают они - указатели.Так адрес - такой же индекс массива. Просто в этот массив вложено все остальное и он называется памятью. В конечном итоге память - массив запоминающих ячеек. Есть еще всякая там трансляция виртуальных адресов в физические и прочая, но прикладникам про это знать вообще нафиг не упало, они это не увидят никогда.
моноид в моноидальной категории эндофункторов.
> Считается что большинство людей по какой-то причине неспособны понять концепцию указателей.И эта причина - отсутствие функционального головного мозга при огромной креативности (т.е. высокой активности спинного). Симптомы - полагаются на существование "универсальных паттернов программирования" для большинства/всех языков, которые достаточно вызубрить...
>Считается что большинство людей по какой-то причине неспособны понять концепцию указателей.Не знаю, во всех ли Паскалях, но в Турбо были указатели. А ещё Турбо Паскаль хорош тем, что у него есть модульность, конкатенация строк, булевый тип и множества на уровне языка, в отличие от Си. Си как язык очень примитивен (это я имею в виду без библиотек, даже стандартных) и содержит массу способов писать неочевидный код. Паскаль, по крайней мере в его Турбо реализация фактически являющейся вариантом Модулы, очень недооценён.
Вы забыли сказать, что он мертв уже лет 15.
> Вы забыли сказать, что он мертв уже лет 15.жив в реинкарнации free pascal. Директива компилятору - {$TP}.
А еще его можно под dosbox запустить. Во всяких школах и ВУЗах так и делают, не переучивать же не блещущих интеллектом преподов и не переписывать же программу. Вот только поднятый из могилы зомби все-равно остается мертвяком, даже если умеет шевелить лапками.
> А еще его можно под dosbox запустить. Во всяких школах и ВУЗах
> так и делают, не переучивать же не блещущих интеллектом преподов и
> не переписывать же программу. Вот только поднятый из могилы зомби все-равно
> остается мертвяком, даже если умеет шевелить лапками.Реализация мертва, диалект нет. Также, как сейчас пишут на ansi c. Или вообще на си, он давно зомби, но не будем об этом :D
> Си. Си как язык очень примитивен (это я имею в виду
> без библиотек, даже стандартных)И это зачастую фича, а не баг. По этому поводу он может работать например "совсем без рантайма". То-есть с места в карьер код и более нифига. А теперь прикинь что это ранняя инициализация системы и вокруг нет гигазов памяти еще, и вообще, шаг влево, шаг вправо - и все повисает.
> и содержит массу способов писать неочевидный код.
А бензопилой вообще можно покалечиться. И чего?
> Паскаль, по крайней мере в его Турбо реализация фактически являющейся вариантом
> Модулы, очень недооценён.Почему же, для обучения нормальная штука. Покажет как надо. Но после сей на нем программить что-то не хочется, извините :).
> Считается что большинство людей по какой-то причине неспособны понять концепцию указателей.указатели, стек, куча, компилятор, препроцессор, void, null, заголовки и непонятные проверки на загруженность одной копии хидера (емнип, забыл нахер это всё как страшный сон :D).
Всё это понадобилось чтоб просто написать один достаточно маленький код. Сишка - грузит знаниями ненужных вещей, архитектуры железа, которые просто необходимо знать, чтоб написать работающее приложение. По крайней мере - стабильно работающее, уж не говоря про безопасное.
> По крайней мере - стабильно работающее, уж не
> говоря про безопасное.Ты не напишешь ни стабильное, ни тем более безопасное приложение ни на одном ЯП. Просто потому что тыр-пыр-восемь-дыр - это не "стабильное и безопасное приложение". Это кусок кривого гомнокода от скрипткидиса, не знающего массу базовых вещей, но мнящего себя пупом земли и экспертом мирового класса. Что как раз очень способствует небезопасности и глюкавости программ.
>> По крайней мере - стабильно работающее, уж не
>> говоря про безопасное.
> Ты не напишешь ни стабильное, ни тем более безопасное приложение ни на
> одном ЯП. Просто потому что тыр-пыр-восемь-дыр - это не "стабильное и
> безопасное приложение". Это кусок кривого гомнокода от скрипткидиса, не знающего массу
> базовых вещей, но мнящего себя пупом земли и экспертом мирового класса.
> Что как раз очень способствует небезопасности и глюкавости программ.никто никем себя не мнёт, не наезжай на меня))
Да это даже не столько наезд, сколько капитанинг :(.
> Да это даже не столько наезд, сколько капитанинг :(.нострадаминг это, вангинг (прости господи), и придуминг с потолкинг) Проще говоря - переходинг на личностинг)
Ну, блин, а что делать если "ламер - это чайник, который мнит что круто заварен"? При этом любители питона как правило не знают самых базовых вещей и страдают велосипедизмом в хучшем виде, т.е. "чайник" - имеется. А ЧСВ и апломб, всякое там показное презрение к ручному управлению памятью и прочему - "мнит что круто заварен".
> Ну, блин, а что делать если "ламер - это чайник, который мнит
> что круто заварен"? При этом любители питона как правило не знают
> самых базовых вещей и страдают велосипедизмом в хучшем виде, т.е. "чайник"
> - имеется. А ЧСВ и апломб, всякое там показное презрение к
> ручному управлению памятью и прочему - "мнит что круто заварен".ладно, так и быть, я ламер, чайник и велосипедист, убедил. Считаю тебя идиотом, а себя крутым кодером. Просто не хотел сразу признаваться, прости.
> Паскаль всё так же преподают. Хотя неясно, в чём проблема изучать Си,
> если даже школьники с этим справляются.А зачем тратить время на то, что не должно изучаться в рамках предмета, Си позволяет сделать больше трудноуловимых ошибок, в итоге при неудачном стечении обстоятельств предмет может превратиться в "поиск ошибок и описок в коде на языке Си".
> А зачем тратить время на то, что не должно изучаться в рамках
> предмета, Си позволяет сделать больше трудноуловимых ошибок,Больше чем ... что? Чем гвидобэйсик? ЩАЗЗЗЗ. Си обложит вас по несовпадению скобок, etc - вы заметите что логика программы не та которую вы задумывали из-за косяка. В питоне же можно стереть пару отступов. Ошибок не произойдет, просто втихаря сломается логика. А вот найти это потом будет крайне нетривиально.
И вообше, вы знаете, как-то по моим наблюдениям, программы нв си - намного предсказуемее и надежнее чем программы на питоне, которые ломаются всегда и везде, при малейшей неидеальности.
> Си обложит вас по несовпадению скобок, etcНу вот в C++ вот это строчка:
A a(i);
может быть и созданием объекта на стеке и объявлением функции. Но большинство ошибок идет не из-за синтаксиса, а семантики.> В питоне же можно стереть пару отступов.
Это часто заканчивается исключением SyntaxError. Зато обязательные отступы защищают глаза преподов от вытекания
> И вообше, вы знаете, как-то по моим наблюдениям, программы нв си -
> намного предсказуемее и надежнее чем программы на питоне, которые ломаются всегда
> и везде, при малейшей неидеальности.Они до первого SIGSEGV/переполнения/etc. предсказуемы. За надежностью программ на С стоит много пота, крови и бессонных ночей их разработчиков.
> Ну вот в C++ вот это строчка:Алё! Мы про си вроде? Си++ уже совсем другое дело. Си++ сложен и вообще совсем не для нубов. Учиться программировать на си++... ну, знаете, тогда учиться ходить надо начинать с паркура и альпинизма, а катание на велике - со спуска по даунхильной трассе. Я вас правильно понимаю?
> Это часто заканчивается исключением SyntaxError.
Ни разу не обязано.
> Зато обязательные отступы защищают глаза
> преподов от вытеканияВон тут Шигорин приводил пример очень читаемого кода. Он, конечно, отформатирован, но радости с этого немного.
> Они до первого SIGSEGV/переполнения/etc. предсказуемы.
SIGSEGV как правило вылезает быстро и по бэктрейсу найти проблемное место как раз не сложно. А вот случайно сломанную логику программы найти, если там никаких ошибок синтаксиса - это уже да, знатный кластерфак вырисовывается. Так можно неделю ломать бошку, чтобы потом хлопнуть себя по лбу - ой, ну вот же, тут пары пробелов не хватает.
Не знаю какой пудак придумал формировать логику отступами, но мне эта идея кажется идиoтизмом в терминальной стадией. Маркеры начала и конца логического блока все-таки позволяют ловить дурные ошибки такого типа по несовпадению пар маркеров.
> Не знаю какой пудак придумал формировать логику отступами, но мне эта идея
> кажется идиoтизмом в терминальной стадией. Маркеры начала и конца логического блока
> все-таки позволяют ловить дурные ошибки такого типа по несовпадению пар маркеровДва отступа это очень много, трудно не заметить оператор, который "свалился" не в свой блок
> Два отступа это очень много, трудно не заметить оператор, который "свалился" не в свой блокЧтобы врубиться задуман вон там стертый отступ или нет - надо парсить весь блок и детально врубаться в контекст. А вот это долго и нудно. А если кода мег - програмер озвереет быстрее чем поймает такой баг, пожалуй.
А что должно изучаться в рамках предмета?
> Паскаль всё так же преподают. Хотя неясно, в чём проблема изучать Си, если даже школьники с этим справляются._отдельные_ школьники справляются! Из своего опыта скажу: я ТРИ раза брался за Си (из них - два, когда уже знал Паскаль!!) и только с третьего раза "въехал" что там к чему. Все эти int a = b++ + ++c; сильно сбивают с толку. Или вообще for(;;IsIt()) - непонятно что происходит там, где даже ничего не написано! :)
Всё же Паскаль полегче дался (да и тот - после Бейсика), так что для начала я б давал ученикам ТОЛЬКО Бейсик - хотя бы понять суть п-я и что ты не только командуешь, но и несёшь ответственность за приказы. А потом уже хоть Смоллток - по накатанной легче.
> Всё же Паскаль полегче дался (да и тот - после Бейсика)Бэйсик как раз все портит. Начинать с паскаля - просто и понятно. Если, конечно, вы вообще хоть как-то способны к программированию. Бывают люди у которых просто проблема с логическим мышлением. Им все ЯПы не даются совершенно одинаково - они будут делать глупейшие ошибки на любом ЯП.
>> Паскаль всё так же преподают. Хотя неясно, в чём проблема изучать Си, если даже школьники с этим справляются.
> _отдельные_ школьники справляются! Из своего опыта скажу: я ТРИ раза брался за
> Си (из них - два, когда уже знал Паскаль!!) и только
> с третьего раза "въехал" что там к чему. Все эти int
> a = b++ + ++c; сильно сбивают с толку. Или вообще
> for(;;IsIt()) - непонятно что происходит там, где даже ничего не написано!
> :)я до сих пор не въезжаю)) неоднозначность и запутанность синтаксиса это еще ладно, нелогично void и null в использовании, легаси бред с функциями, где если функция не возвращает значение пишем void func(), а если возвращает то просто func(). А отсутствие нетрансцендентных строк, массивов, модулей и пространств имён - сделали сишку вообще архаичным старьём и как-то даже не мотивирует изучать. Но хочется, чтоб иногда системный код понимать и по возможности поправить.
Системщики возможно ведают что творят, но в прикладном программированиии использование Си у меня ассоциируется с кнутом и латексом))
> в прикладном программированиии использование
> Си у меня ассоциируется с кнутом и латексом))во всех остальных случаях не лучше.
к сожалению, на си сделана куча кода, а компиляторы си есть чуть ли не для табуретов.
с другой стороны — вполне можно использовать си так, как делают сейчас некоторые трансляторы: выплёвывая вместо ассемблерного кода сишный и пиная си-компилятор «под ковром».
правда, и для такого применения си не очень подходит — с его идиотскими UB (переполнение беззнакового целого определено, знакового — нет; доступа к carry flag, имеющемся на подавляющем большинстве процессоров — нет… а, долгая, печальная история).
> идиотскими UB (переполнение беззнакового целого определено, знакового — нет; доступа
> к carry flag, имеющемся на подавляющем большинстве процессоров — нет… а,
> долгая, печальная история).Ну транслируй, блин, в ассемблер, если такие навороты надо. Carry флаг тоже еще явно проверять надо, btw. И если это делать после каждой команды - скорость свалится чуть ли не вдвое :).
> Ну транслируй, блин, в ассемблер, если такие навороты надо.в чей именно? а-а-а, «целевой системы»? или в два. или в три. или…
> Carry флаг тоже еще явно проверять надо, btw.
и это, конечно, очень мешало добавить в си предикат is_carry(expression). ведь это же совсем-совсем неприкольно: использовать то, что умеет большинство процессоров аппаратно вместо написания кучи идиотских ручных проверок, где шанс ошибиться намного выше. «язык системного программирования», my ass…
> же совсем-совсем неприкольно: использовать то, что умеет большинство процессоров
> аппаратноА если некто не умеет - то чего? Посадить ему скорость математики в несколько раз, проверяя все операнды программно?
> «язык системного программирования», my ass…Дык, твой ass ничего лучше не предложил.
Хотя в целом соглашусь что фичу можно было бы и сделать, временами удобно было бы.
разупорись, пожалуйста.
p.s. или, например, посчитать количество архитектур, которые используют two's complement integer arithmetic и сообразить, что для «процессоров в будущем, которые будут импортированы с Марса» можно будет ввести новый тип целых, а сейчас намного удобней сделать результат переполнения int определённым (равно как и результат приведения signed<->unsigned одинакового размера).но нет, это было бы слишком просто, это же, в конце концов, Крутой Язык Системного Уровня! стоит ли облегчать жизнь этим дуракам-системщикам? да ни за что, им же так нравится городить ручные проверки там, где уже есть аппаратные, и либо жертвовать переносимостью кода (и дрожать от предвкушения того, что сделает оптимизатор, увидев код с UB), либо опять писать руками преобразования, которые аппаратно не более, чем обычный mov.
> намного удобней сделать результат переполнения int определённымУ разных процессоров и компилеров разный int. На лично мое мнение стоило бы вообще забить на эти int и что там еще и использовать нечто типа u8...64, s8...64 и так далее - сущности с известным размером и определенным результатом переполнения. Но увы, мир неидеален.
> опять писать руками преобразования, которые аппаратно не более, чем обычный mov.
У некоторых процов mov может и не быть. Как и carry.
>> намного удобней сделать результат переполнения int определённым
> У разных процессоров и компилеров разный int.точно? точно-точно? а ну-ка, давай рассказывай, где какие. у каких процессоров int — не two's complement, сколько таких, и сколько процессоров, где two's complement?
> бы вообще забить на эти int и что там еще и
> использовать нечто типа u8...64, s8...64 и так далеепри чём тут размеры инта? O_O ты чем читал вообще? unsigned int тоже не особо определён в точных размерах, но оговорить в стандарте поведение uint при переполнении это отчего-то никому не помешало.
>> опять писать руками преобразования, которые аппаратно не более, чем обычный mov.
> У некоторых процов mov может и не быть. Как и carry.и сколько их? а сколько тех, у кого есть? намекаю: не большинство должно забивать на фичи, потому что их нет у двух инвалидов, а инвалиды должны эмулировать фичи, которые есть у большинства.
> точно? точно-точно? а ну-ка, давай рассказывай, где какие. у каких процессоров int
> — не two's complement, сколько таких, и сколько процессоров, где two's complement?Они по размеру разные. Могут быть - bмеют право. У одних чуваков вообще char был 16-битный. Не потому что они уникод любят, а потому что их DSP напрочь не умеет работать с отдельными байтами. Определения базовых типов в сях и работа с ними вообще странные и оставляют желать.
> при чём тут размеры инта? O_O
А том, что если уж докапываться до работы с числами, размерность стандартных типов и все что вокруг - достаточно популярный источник грабель. В том числе и ведущих к переполнениям. Вон какой-нибудь автор LZ4 по жизни юзает 64-битную платформу, а проблемы нег^W 32-битных платформ его взволновали только после наглого жирного CVE...
> ты чем читал вообще? unsigned int тоже не особо определён в точных размерах,
Именно int - да, всякие (u)intXX_t - уже более определенные, хотя и тоже несколько через ж, ибо могут быть как равны желаемому размеру, так и больше чем.
> но оговорить в стандарте поведение uint при переполнении это отчего-то
> никому не помешало.Да это был как еще 1 пример бестолковостей с типами. Если там докапываться - там много к чему докопаться можно.
> и сколько их?
Не знаю. Процов много разных бывает, вплоть до самопалов на FPGA и академизвращений типа subleq.
> а инвалиды должны эмулировать фичи, которые есть у большинства.
Да вообще пожалуй валидный пойнт. Правда опять же - а как carry вывешивать, чтобы математика не тормознула в разы? В лучшем случае математика укладывается в 1 регистровую операцию, напрямую буквально. Посмотреть что в carry - минимум еще 1 операция на большинстве процов. Т.е. математику можно минимум в пару раз посадить. Был бы это дотнет - там бы наверное сделали. А тут ... кому сильно надо, аргументы может и сам проверить. И вопрос еще - хуже ли это чем всю математику по скорости убить в разы дополнительными проверками carry в каждом закоулке.
> Они по размеру разные.я всё равно из текста не понял, каким образом здесь *размер* относится к *представлению*. кроме того, что в Африке негры, а на орбите спутник.
> Да это был как еще 1 пример бестолковостей с типами.
ты как-то выделяй это, что ли. а то получалось, что «неопределённость размера инта не позволяет определить результат переполнения.»
>> и сколько их?
> Не знаю. Процов много разных бывает, вплоть до самопалов на FPGA и
> академизвращений типа subleq.это круто. но тем не менее подавляющее большинство универсальных процессоров с целыми работает одинаково, имеет регистры, mov и carry flag. только комитету по стандартизации «близкого к железу» языка об этом почему-то никто не рассказал, а сами они никак узнать такое не могли.
> Правда опять же - а как carry вывешивать, чтобы математика не тормознула в разы?
элементарно. я тебе сейчас страшную штуку скажу, ты приготовься: можно иметь математику и с проверкой, и без проверки! понимаю, сразу до такого не додумаешься, эту сложную идею надо долго переваривать.
прикинь: добавить, например, какой-нибудь iscarry(expr) — и… и опа! Очень Сложная Проблема успешно решена, потому что внутри expr си допускает всякие присваивания и прочие гитики. это так, простейшее решение за перекуром. что самое смешное — даже такое простое решение покроет огромное количество случаев, убрав многие идиотские танцы со сравнениями. и при этом если проверки не нужны — их точно так же не делают, как и раньше. ЧУДО!
Я Бейсик помню!
Название?
> Ага, Паскаль и Бейсик тоже были в топе у школьников/студентов много летНу так питон - такой себе Бейсик 2.0...
я помню паскаль (Turbo PAscal 7.0 ), так как с него начинал, но потом уверенно на С перешел, паскаль устарел, хотя для обучения пойдет.программирование в школе мало кто понимает, только единицы. Не всем суждено стать программистом.
Basic только пару программ и кинул его. паскаль научил порядку, своими var, и нормальным синтаксисом написания, в стиле begin .. end.
Эх веселые были дни, помню тогда у нас с братом инета не было, ошибки все исправляли головой, я даже придумал как русскими буквами писать ))). Потом помню нашелдиск с дельфи 3 и 7 версией и Borland C++ 5.02, даже учитель информатики спросил где это достал ))))
А на озеро вы с ребятами ходили?
Расскажите, очень интересно.
окагжы sicp и scheme???!!!
> окагжы sicp и scheme???!!!Книжка бесплатная, интерпретатор бесплатный учи на здоровье.
>Daniel Weinreb has a short investigative piece about why MIT's well-known 6.001 course based around SICP and Scheme has been replaced with Python
Несколько лет назад курс был переведён на Питон. Во многом из-за этого его популярность так и выросла.
Ещё одним фактором популярности стали библиотеки numPy, sciPy и другие научной направленности. Стало возможным использовать Питон вместо Матлаба для многих типов задач. В том числе для обработки изображений, используя биндинги к OpenCV.
> Несколько лет назад курс был переведён на Питон. Во многом из-за этого
> его популярность так и выросла.
> Ещё одним фактором популярности стали библиотеки numPy, sciPy и другие научной направленности.
> Стало возможным использовать Питон вместо Матлаба для многих типов задач. В
> том числе для обработки изображений, используя биндинги к OpenCV.Негуманно это заставлять научных работников писать на питоне. Для истинных математиков есть R, для прочих - Ruby. А хочется заменить Simulink, есть KNIME + Ruby.
Питон - старый язык с устаревшим же синтаксисом. И никакие изменения версий и синтаксические плюшки его не исправят. В лучшем случае он просто станет новой версией Ruby.
>Негуманно это заставлять научных работников писать на питоне.Они взрослые, они сами выберут.
>для прочих - Ruby.
>Питон - старый язык с устаревшим же синтаксисом.У руби синтаксис унаследованный из algol-а и перла.
Надо полагать идеология блоков взята с перла?... Особенно в части each, times, map, select, reduce, find, detect и пр.?
А откуда же еще?Matz взял Perl, "сузил" его, прибил к нему гвоздями дурно понятое ООП, и потратил оставшееся время на отрицание этого факта.
Matz факты влияния не отрицает. Даже не отрицает то, что ему нравился питон на тот момент.А вот прежде чем выносить столь странные суждения неплохо бы с Ruby ознакомиться. Заявления типа "а я на хабре статью прочитал" здесь не пойдут. Это не тот язык, понять который можно за 10 минут. Хотя, действительно, за 10 минут можно научить писать на нём программку типа ввести abc, вывести 123.
Поначалу не отрицал, за очевидной глупостью такого отрицания. А вот когда юных рубистов поднабралось заметное количество - как-то всё меняться в сторону "Океания никогда не воевала с Остазией".В чем же предполагаемая вами странность суждений? Ввести дополнительную, весьма ограниченную сущность только ради экономии пары символов вместо совершенно обычного применения first-class functions - это классический случай "сузить".
Кстати, добавлю о ваших любимых изобретенных в Ruby блоках - http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.htm...
> Кстати, добавлю о ваших любимых изобретенных в Ruby блоках - http://web.cecs.pdx.edu/~harry/musings/SmalltalkOverview.htm...Отсылки к Smalltalk в части синтаксиса ранее не было..... Да, ООП, блоки концептуально взяты из Smalltalk. Но явно не перла. Впрочем, кто сейчас готов создавать проект на Smalltalk?
"экономия пары символов" - это читаемость кода. Лишние сущности же в Ruby назвать довольно сложно.
"Сужение" здесь позволило довольно органично вписать как функциональный стиль:
https://code.google.com/p/tokland/wiki/RubyFunctionalProgram...
так и возможности написания многочисленных DSL и DSEL, весьма приближаясь к концепции естественного языка: rspec, chef, god...
> Да, ООП, блоки концептуально взяты из Smalltalk. Но явно не перлаЭто вот откуда следует? У Обамы вот второе имя - Хусейн, они, по вашему мнению, с Саддамом - родственники на этом основании?
> "экономия пары символов" - это читаемость кода.
Тогда APL - самый легкочитаемый код на свете.
> Лишние сущности же в Ruby назвать довольно сложно.
Я уже назвал, чтоб вам было проще - те же блоки.
> "Сужение" здесь позволило довольно органично вписать как функциональный стиль
Это не функциональный стиль, а пародия на него. Ну ок, можно назвать имитацией чтоб не было так обидно.
Те же map {} и grep {} сотоварищи в Perl и выглядят куда чище, и никаких специальных блоков для этого вводить не нужно.
В части источников вдохновения и Smalltalk. Matz ничего не скрывает до сих пор:https://www.ruby-lang.org/en/about/
http://www.infoq.com/interviews/yukihiro-matz-language-designВ части "лишней сущности". Что легче воспринимается (пример из RSpec):
describe "launch the rocket" do
context "all ready" do
end
context "not ready" do
end
endИли вариант без блоков (если использовать лямбду, то блоки всё равно будут присутствовать для определения лямбды):
def context_block1
...
enddef context_block2
...
enddef describe_block1
context "all ready", &context_block1
context "not ready", &context_block2
enddescibe "launch the rocket", &describe_block1
Итого, да, можно обойтись без блоков. Но в первом случае мы приближаемся к концепции текста программы как текста на естественном языке, во втором - я бы так разговаривать не стал....
В части чистоты map. Пример для Ruby:
"12 23 34 45 56".split.map(&:to_i) # => [12, 23, 34, 45, 56]
[12,23,34,45,56].map{ |x| x*x ).select{ |x| x % 5 }Всё читается даже, если синтаксисом знаком плохо.
> Matz взял Perl, "сузил" его, прибил к нему гвоздями дурно понятое ООП,
> и потратил оставшееся время на отрицание этого факта.А вы лучше всех знаете как надо, но нифига не делаете. Поэтому будете жpaть что дали...
> А вы лучше всех знаете как надо, но нифига не делаете. Поэтому
> будете жpaть что дали...в отличие от однобитных анонимусов, у которых выбор — это всегда два варианта, у других область выбора часто включает намного большее количество вариантов. поэтому пока половина однобитных жрёт, что дают, а вторая половина усиленно велосипедит очередную бесполезную ерунду, разумные люди спокойно используют доступные инструменты. к удивлению однобитных — вовсе не Один Священный Инструмент.
>разумные люди спокойно используют доступные инструменты. к удивлению однобитных — вовсе не Один Священный Инструмент.Обычно такие заявы используются в сра^W дискуссиях Lin/Win, Lin/Mac и т.д. и вызывают у местной фауны дикое бурление и пускание пузырей.:)
(пожимает плечами) винда — очень неудобный инструмент. в большинстве случаев выбрать его можно или от полной безысходности, или за большие деньги. а макось вообще выбирать бессмысленно, потому что ничего такого, что нельзя было бы сделать с другой системой, она не умеет.впрочем, это тоже зависит от задач: например, городить виндосетку с серверами на самбе не обязательно будет удобней и эффективней, нежели с серверами на винде. другое дело, что лучше виндосетками и вовсе не заниматься, это плохо влияет на пищеварение и цвет лица.
> к удивлению однобитных — вовсе не Один Священный Инструмент.Правда, в результате программ никто и никогда не увидит, да и переписывать весь софт - задолбает :).
P.S. а вообще trolling success, Кэп купился :)
кто купился — вопрос очень спорный.
> А откуда же еще?ну нельзя же так толсто.
>> А откуда же еще?
> ну нельзя же так толсто.А что, таки неужели действительно напрямую из Smalltalk?
Может, конечно, быть и такое, но было бы несколько странно - всё взять из перла, а именно это - нет.
> А что, таки неужели действительно напрямую из Smalltalk?насколько я помню — смолтолк указывался как один из источников вдохновения. оно, кстати, и видно. так что я бы поставил на смолтолк всё-таки.
Для истинных математиков есть бумага с карандашом.А R и прочие числодробления - это для прикладников, или, что еще хуже, статистиков, с которыми истинные математики (которых порядка 3-5 тысяч на всю планету) рядом и не сядут.
> Для истинных математиков есть бумага с карандашом.
> А R и прочие числодробления - это для прикладников, или, что еще
> хуже, статистиков, с которыми истинные математики (которых порядка 3-5 тысяч на
> всю планету) рядом и не сядут.Справедливости ради, задачи ( в механике правда ) по движению/колебаниям которые возникают в том числе в научных кругах, не всегда удобно даже записывать ручкой на бумаге.
> Справедливости ради, задачи ( в механике правда ) по движению/колебаниям которые возникают
> в том числе в научных кругах, не всегда удобно даже записывать
> ручкой на бумаге.В научных кругах много разных задач возникает - в том числе и пробирки помыть, и численных экспериментов произвести. Только чистые математики такими задачами не занимаются.
> Только чистые математики такими задачами не занимаются.Да ладно, не только математики. Я вот после ванны тоже не люблю всякой хернёй маяться. Люблю посидеть, посозерцать, подумать о высоком.
Да нет, это просто недоразумение.
Когда вам сказали что индекс Хирша надо содержать в чистоте, ванны в виду не имелось, имелись в виду трудолюбивые китайские математики, пишущие по 5 статей на каждое изменение коэффициентов в решенном их научном руководителем уравнении.
> Негуманно это заставлять научных работников писать на питоне.+1000.
Пейстон - он и для нормальных-то программистов - вычурный, да ещё с отступами как в заплесневелом фортране! Научным трудягам нужен предсказуемый, _простой_ язык с кучей внутренних функций. D тут был бы в самый раз.
Если бы не бы, то ух бы!
(С)Про D одной фразой.
> Если бы не бы, то ух бы!это было мнение анонимуса, в ужасе убежавшего при виде writeln().
Покажи свой код ариша, или гэть на кухню борщ варить!
что, тебе код для показа на собеседовании нужен, и ты так бездарно его пытаешься выпросить? сам пиши.
Я те про ди литературный одностричник вЫдал.
А твой талант так и останется неоценЁнным :)))
Scheme не все осиляют. Да и уровень задач в SICP даже в первой главе на голову выше задач из курсов среднего технического ВУЗа.
> Scheme не все осиляют. Да и уровень задач в SICP даже в
> первой главе на голову выше задач из курсов среднего технического ВУЗа.Истинно так! Но, книжка хороша. Читаю и нарадоваться не могу. Всё объясняется предельно просто и понятно. А что не понятно - в процессе решения задач стремительным домкратом вбивается в голову. Зело кошерная книга!
> Scheme не все осиляют.до сих пор все «неосиляторы», которых я видел, делятся на два вида:
1) те, кто даже и не пытались, а сразу начали рассказывать про «скобки» и «неудобно»;
2) дебилы.
В хороших вузах не важно какой язык используют, так как там учат не языку а програмированию.
В плохих вузах не важно какой язык используют, так как они плохие.
Для хорошего студента не важно какой язык подают на лекциях, так как лекции составляют 5% от источников его знаний.
Для плохого студента не важно какой язык подают на лекциях, так как лекции составляют 0% от источников его знаний.
Просто тебя дрючили паскалем, и ты завидуешь.
> Просто тебя дрючили паскалем, и ты завидуешь.У меня тоже был паскаль в институте, только меня им не дрючили, так как я знал его лучше препода и помогал ему проверять работы группы. Если вам некому позавидовать - you're welcome!
Кстати, знание Барсика и Паскакаля отнюдь не помешало мне потом познакомиться с асмом, а затем уйти на си с крестами. После которых эти ваши Пыхи, а также Жабы со скрипом и без - ну, полистал учебник, и поехали... Очевидно же, откуда что растет.
на моей памяти толковые студы забивали на условности, и выполняли работы на том, на чём нравилось. преподы как правило не возражали, а если за работой стоял заказчик в виде живой конторы, приветствовали (ну это ближе про диплом).
>Для плохого студента не важно какой язык подают на лекциях, так как лекции составляют 0% от источников его знаний.а что составляет оставшиеся 100 процентов его знаний?
>а что составляет оставшиеся 100 процентов его знаний?bash.org, lurkmore и этикетка от пива поровну.
> bash.org, lurkmore и этикетка от пива поровну.Состав освежителя забыл.
А вот лурку трогать не надо - там всё путём!
> А вот лурку трогать не надо - там всё путём!Да, про вас там очень честно написано, правда вы у нас скромный и приставку где-то потеряли.
Вы живете в черно-белом мире, где не бывает промежуточных состояний?
Только заметил?
> Только заметил?Есть только 10 видов людей - те которые понимают бинарную логику и те которые нет.
Нет бы нормальный руби использовать. Зачем питоном калечить души?
Вы — web-разработчик. Угадал?
Нет.
Ладно. А какая первая буква?
> Ладно. А какая первая буква?А
Простой аноним же.
> Вы — web-разработчик. Угадал?нет, он wannabe.
А нам на 1-м курсе вообще С++ с ассемблерными вставками...
> А нам на 1-м курсе вообще С++ с ассемблерными вставками...Естественный отбор...
>> А нам на 1-м курсе вообще С++ с ассемблерными вставками...
> Естественный отбор...Да это не "отбор", это уже Спарта какая-то!!!
> Да это не "отбор", это уже Спарта какая-то!!!Зато те кто выживут - будут нормальными програмерами, не то что вы.
Значит задача состояла в сокращении бюджетных мест.
Питон не проще С++. Если же ассемблер изучать на микроконтроллере, то и он совсем простая штука, пять команд, да пара регистров и вперед ногами МК дрыгать. Так что если процесс обучения поставлен верно, то любой язык попрет. Главное что бы на практике было применимо.
> Питон не проще С++.Потрудитесь привести аргументы в пользу данного утверждения.
При написания нетривиальной программы на с++ обычно используется более 6-и языков или диалектов.
1. bash - ./configure скрипт
2. make - Мakefile
3. Язык препроцессора #define #ifdef и т.д.
4. Язык шаблонов c++ который сам по себе полон по Тьюрингу (см вычисление факториала в с++ на этапе компиляции)
5. с++11 constexpr - выполняется на этапе компиляции
6. c++ очевидно.
Для написания работающей программы на пайтоне используется ... Пайтон?
>При написания нетривиальной программы на с++ обычно используется более 6-и языков или диалектов.Знатные травы с грибами уродились у вас в этом году.
>Для написания работающей программы на пайтоне используется ... Пайтон?
И что с того. Надо GUI учи Qt, надо веб учи Django/Flask/Twisted/Tornado, надо CV изучай OpenCV, Для использования numpy/scipy/pandas/skikit-learn/sympy/theano надо бы математику знать на уровне математика-выпускника хорошего ВУЗa.
Это я еще про стандартную библиотеку не заикался в которой более 200 модулей.
> Знатные травы с грибами уродились у вас в этом году.Я привел пример сложности С++. Ваш контраргумент?
> И что с того. Надо GUI учи Qt, надо веб учи Django/Flask/Twisted/Tornado,
> надо CV изучай OpenCV, Для использования numpy/scipy/pandas/skikit-learn/sympy/theano
> надо бы математику знать на уровне математика-выпускника хорошего ВУЗa.
> Это я еще про стандартную библиотеку не заикался в которой более 200
> модулей.Какое это имеет отношение к сложности языка?
>Я привел пример сложности С++. Ваш контраргумент?C++ сложен в совершенно другой области.
> Я привел пример сложности С++. Ваш контраргумент?Вы громыхнули бидоном, совершенно не по делу.
Домашнее задание: проверить что у юзера есть бидон, нужной версии и с нужными модулями. То что вы на это положили буй, а авторы си++ной проги на это не забили и сделали через configure - так это, вы почему-то думаете что перепихать все проблемы на юзера - это фича, а не баг. А юзеры вот иного мнения на этот счет...
> Надо GUI учи Qt, надо веб учи Django/Flask/Twisted/Tornado, надо CV изучай OpenCVИ получится не образованный инженер, а дрессированный кодер.
> И получится не образованный инженер, а дрессированный кодер.Ну так и получился, как видим. А как только он не смог найти готовый компонент на мало-мальски нестандартную задачу - ПИ..Ц, ЧУВАКИ, ЭТА ЗАДАЧА НЕРЕШАЕМА!!!
>> Надо GUI учи Qt, надо веб учи Django/Flask/Twisted/Tornado, надо CV изучай OpenCV
> И получится не образованный инженер, а дрессированный кодер.Образованный инженер -- это тот кто пишет велосипеды?
> Образованный инженер -- это тот кто пишет велосипеды?Образованный инженер - это человек который умеет думать головой. В объеме несколько превышающем упомянутые вами условные рефлексы примитивных существ.
> 1. bash - ./configure скрипт
> 2. make - МakefileЭтой гадости больше нет, есть один cmake. Для питона тоже есть pydistutils.
Остальное - один язык, разделять его - как разделять питон, ООП питона и функциональные возможности питона. И да, он намного богаче питона и именно поэтому он лучше подхдит для обучения. И нет, он не сложнее.
>Этой гадости больше нет,Как нет? Куда делись?
>есть один cmake.один cmake, один automake, один premake, один qmake, один qbs, один SCons, один waf один... и это все только для сборки.
>Остальное - один языкРасскажите мне еще раз что язык препроцессора и С++ это один язык. Заодно расскажите это Страуструпу, а то он другого мнения.
>И нет, он не сложнее.И нет вы не привели ни одного аргумента. Аргумент от меня. Спецификация с++ превосходит 1000 страниц, что в разы (около 10?) больше чем аналог от пайтона.
>И да, он намного богаче питона
>И нет, он не сложнее.Я тут вижу противоречие.
> Заодно расскажите это СтрауструпуЛучше Александреску! В разговоре с ним всегда есть шанс получить шаблон ответа, который будет настолько всеобъемлющ, что на этапе компиляции соберется в 42...
Александреску давно забил на цпп.
А сам Александреску об этом знает?
Вот его доклад на конференции посвященной с++ в 2013
Writing Quick Code in C++, Quickly
http://channel9.msdn.com/Events/GoingNative/2013/Writing-Qui...
Вот его доклад на конференции посвященной с++ в 2012
Variadic Templates are Funadic
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
Надо мне приводит его доклады о С++ в 2011, 2010, 2009 и т. д. годах?
Он, кстати, один из активных консультантов комиссии по стандартизации С++.И один из соавторов Variadic Templates в С++11 и т. д.
Но не обращайте внимания. В вашем воображаемом мире все по другому.
> А сам Александреску об этом знает?знает.
> знает.Как много ошибок в слове "обтекаю"
Мальчики, не ссорьтесь! :-)Александреску, конечно, последние годы играет только в D, но это не означает что он полностью забил на С++.
не то, чтобы «полностью» — конечно, и речуги толкает, и что-то там делает… но цпп неизлечим из-за legacy, и основным интересом не является. это, в общем-то, вполне означает «забил».
Ну вот, у вас просто misunderstanding, не договорились о терминах.
Вы понимате "забил" как "не рассматривает его в качестве светлого будущего", а ваш собеседник как "абсолютно ничего, связанного с С++ не делает, не участвует"
при этом я понял, что он имел в виду, и дал шанс задать уточняющий вопрос, написав нейтральный ответ. оппонент же с огромным удовольствием шанс проигнорировал и вместо этого пожелал раскрыть одну из граней своей глупости. его право.
Продолжайте.
Андрей, залогиньтесь.
> Этой гадости больше нет, есть один cmake. Для питона тоже есть pydistutils.Только почему-то configure+make зарекомендовали себя наименее глючным способом сборки софта. Cmake мало того что отваливается в половине случаев, так еще потом без поллитра не разберешься что сломалось. Логгинг операций там ни к черту.
> При написания нетривиальной программы на с++ обычно используется более 6-и языков или
> диалектов.
> 1. bash - ./configure скрипт
> 2. make - Мakefile
> 3. Язык препроцессора #define #ifdef и т.д.
> 4. Язык шаблонов c++ который сам по себе полон по Тьюрингу (см
> вычисление факториала в с++ на этапе компиляции)
> 5. с++11 constexpr - выполняется на этапе компиляции
> 6. c++ очевидно.Это вы на Мазолинуксе делали. Нормальные прогеры запускают студию, пара кликов - готов проект с main() - внутри пишешь ТОЛЬКО на С++ и этого достаточно. Даже шаблоны можешь использовать только библиотечные - учить "язык шаблонов" для этого не нужно.
> Для написания работающей программы на пайтоне используется ... Пайтон?
Нет. Без грибов Пайтон никогда не используется. Это сродни ЛИСПу - у каждого языка свои пациенты.
> Нормальные прогеры запускают студию,"Проект *** был создан в другой версиии Visual studio. Открыть Мастер преобразования Visual Studio?"
"В процессе преобразования проекта произошла ошибка. Закрыть проект?"
> пара кликов -
> готов проект с main()_tmain(int argc, _TCHAR *argv[]) Что такое _tmain, wmain, #define UNICODE, _TCHAR и как класcно это все отлаживать? вы узнаете на msdn.
>ТОЛЬКО на С++ и этого достаточно.
В проектах VS для windows модно правила сборки писать на C#.
Пример Unreal Engine 4.
> Нормальные прогеры запускают студию,Слишком громкое заявление.
> пара кликов - готов проект с main()
Правда, заслуг програмера в этом вообще никаких нет. С таким же успехом то что вам подарили кирпич - не значит что вы хороший строитель. У вас просто есть кирпич. На умения строить дома это не влияет.
> - внутри пишешь ТОЛЬКО на С++ и этого достаточно.
/me не думает что вы способны нормально писать на си++ :).
> Даже шаблоны можешь использовать только библиотечные - учить "язык
> шаблонов" для этого не нужно.Стесняюсь спросить, а когда рантайм не умеет чего-то - вы тоже рапортуете наверх "задача нерешаема"? Как и питонисты, собственно :)
> 1. bash - ./configure скриптты таки пишешь его руками? ну офигеть.
> 2. make - Мakefile
а, ну да, раз configure руками, то и automake в пролёте.
> 3. Язык препроцессора #define #ifdef и т.д.
за это в цпп рекомендуется сначала обрывать уши, а потом руки.
> 4. Язык шаблонов c++ который сам по себе полон по Тьюрингу (см
> вычисление факториала в с++ на этапе компиляции)если нечто «полное по тьюрингу», это ещё не значит, что надо сразу писать на этом код, использующий данную фичу.
> 5. с++11 constexpr - выполняется на этапе компиляции
конечно, без этого никак вообще. а до 11 жизни не было.
бедняга, тяжело тебе, наверное. ни про библиотеки не знаешь, ни про фрэймворки… скорее всего, даже не поймёшь, к чему я их тут упомянул.
>> 3. Язык препроцессора #define #ifdef и т.д.
> за это в цпп рекомендуется сначала обрывать уши, а потом руки.Прошу пардону, но или вы заговариваетесь, или можете меня чему-то научить.
Простейший пример: есть программа, функциональность которой разграничена: для внутреннего применения - весь фарш, для внешнего - огрызок и лично для Андрея - кое-что сверх огрызка. Соответственно выделены блоки #ifdef PRO_VERSION, #ifdef ANDREW_VERSION... и выставлены соответствующие -D-флаги в настройках проектов компиляции. Код един, исключение блоков совершенно безболезненно.Вы можете рассказать, почему это неверно и как надо сделать это правильно?
> Вы можете рассказать, почему это невернопотому что у апологетов цпп ненависть к препроцессору. отчасти даже оправданная.
> и как надо сделать это правильно?
выделить унифицированный интерфейс, на этапе конфигурации проекта подставлять нужную реализацию этого интерфейса.
> выделить унифицированный интерфейс, на этапе конфигурации проекта подставлять нужную
> реализацию этого интерфейса.А когда у нас есть две версии сторонней библиотеки, и надо уметь линковаться и с той и с другой, а интерфейс у неё сильно поменялся - что в таком случае препроцессоро-отрицатели рекомендуют?
питон.
> питон.А он каким-то волшебным образом узнает как именно поменяли апи в новой версии либы? Там что, AI встроен?
> А когда у нас есть две версии сторонней библиотеки, и надо уметь
> линковаться и с той и с другой, а интерфейс у неё
> сильно поменялся - что в таком случае препроцессоро-отрицатели рекомендуют?выделить унифицированный интерфейс, на этапе конфигурации проекта подставлять нужную реализацию этого интерфейса.
Так чем подставлять-то? Неужто автотулсами?
> Так чем подставлять-то? Неужто автотулсами?можно и ними. той системой конфигурирования проекта, которая в нём используется, собственно. лично у меня вообще своя система сборки, некоторые другие возможные варианты тут тоже перечисляли.
Ну то есть все претензии - не к самому #ifdef LIB_VERSION, а к тому кто или что именно будет его туда автоматически или вручную вписывать?
Или вы полагаете принципиальным различием если вместо ifdef-a внутри одного хидера мы вынесем варианты в два разных хидера и система сборки будет их тасовать в виде файлов?
у меня вообще нет претензий, это у апологетов «чистоты цпп» есть. а я просто в них играю.но я и сам считаю, что вместо таких ifdef'ов лучше всё-таки сделать разные файлы и собирать с соответствующим. оно так красивей будет.
> «чистоты цпп»Звучит как оксюморон.
> но я и сам считаю, что вместо таких ifdef'ов лучше всё-таки сделать
> разные файлы и собирать с соответствующим. оно так красивей будет.До некоторой степени - да, конечно, вопрос, как всегда - вовремя остановиться чтоб не плодить сотни этих мелких фрагментов. Как и с любыми best practices - без здравого смысла всё равно плохо получится.
> вместо таких ifdef'ов лучше всё-таки сделать разные файлыПример: сейчас в исходниках прописано меню программы. Добавляются пункты, часть их огорожена #ifdef и добавляется только в про-версии. В классе документа есть функции, вызывающиеся только в про-версии. Компилятор их выкидывает, если версия не про и они ни разу не вызываются.
Вы же всерьез не рассматриваете вариант вместо этого плодить копии файлов, отличающихся только наличием или отсутствием этих пунктов меню и этих функций? It smells!
(пожимает плечами) поскольку это как минимум две точки синхронизации, кто мешает объединить в одну? меню формируется динамически после запуска, путём опроса интерфейса «capabilities».ну, или так: каждый модуль, который добавляет что-то в меню, сам там и регистрируется — благо, статические объекты позволяют это сделать почти что красиво, без утомительных прописываний «зарегистрируй меня» в каком-то центральном месте.
много чего, в общем-то, можно придумать, и большинство нормальных способов будет удобней и расширяемей, чем лапша из ifdef'ов.
Это одна точка - при формировании меню.
Не вижу, в чем нагромождение абстракций улучшит этот код. Сопровождение его явно не упростится.
Имхо, это больше похоже на фобию, а не конструктив.
> Это одна точка - при формировании меню.то есть, все функции остались на месте? ах, как чудесно! ещё со времён молодого кулхацкерства любил такой софт!
впрочем, я не окулист, так что дальше беседовать не вижу смысла. когда начнёшь видеть — приходи.
> то есть, все функции остались на месте?Так они в любом случае будут на этом месте. Разрабатывается-то про-версия, которая обладает полным функционалом. Цена лайт-версии - две строчки с # и один ключ при компиляции. Остальное делает компилятор, в том числе и выкидывает из результата ненужный код.
На кой ляд здесь термоядерные абстракции и как они помогут проекту в сколько-нибудь обозримом будущем?
> к тому кто или что именно будет его туда автоматически или
> вручную вписывать?Да хоть те же автотулсы. Или какая там еще система сборки.
Что, никогда не видали #include config.h который заполнен системой сборки для информирования программы о том что там надетектировалось? O_O
>> 3. Язык препроцессора #define #ifdef и т.д.
> за это в цпп рекомендуется сначала обрывать уши, а потом руки.Ваш вариант include guards без препроцессора.
Ваш вариант #ifdef WINDOW #ifdef UNIX для кросплатформенных приложений.
Ваш вариант __LINE__ __FILE__
Ваша замена #ifdef DEBUG
Если у вас есть рабочий, кроскомпиляторный, кросплатформенный вариант include guards без ifdef / pragma оставляйте ваши координаты, вы меня заинтересовали.
> если нечто «полное по тьюрингу», это ещё не значит, что надо сразу
> писать на этом код, использующий данную фичу.Написание нетривиального кода на С++ без Boost затруднительно.
Api библиотек Boost это большое количество шаблонного кода. Весьма большое.
Написание нетривиального кода на С++ без STL затруднительно вдвойне.
Api библиотек STL это большое количество шаблонного кода. Весьма большое.
>> 5. с++11 constexpr - выполняется на этапе компиляции
> конечно, без этого никак вообще. а до 11 жизни не было.Конечно можно. И обходились. С помощью препроцессора.
> бедняга, тяжело тебе, наверное. ни про библиотеки не знаешь, ни про фрэймворки…
> скорее всего, даже не поймёшь, к чему я их тут упомянул.Я сомневаюсь, что вы разбираетесь в С++, хотя бы на уровне junior developer, вы уж извините.
Но, у вас есть шанс меня переубедить.
Опишите пожалуйста основную проблему следующего кода:
class Point{
public:
int x;
int y;
Point(...){...}
virtual ~Point(){...}
};
int main(){
...;
Point *p = new Point(...);
// ... - некий, не важный для нас, код.
}
Вы производите впечатление форумного теоретика.
Ой, а можно я С++ повспоминаю?Проблемы я тут не вижу, кроме того что деструктор объявлен виртуальным почем зря, только памяти лишней таблица виртуальных функций немножко съест - но я бы не считал это проблемой.
А что еще - исключение, которое может возникнуть в конструкторе не обрабатывается?
да всё там нормально: типичный throw-away code, написали как написалось. без чёткого описания требований основная проблема этого кода в том, что его в качестве вопроса привёл дебил.
> да всё там нормально: типичный throw-away code,Верно.
>написали как написалось. без чёткого
> описания требований основная проблема этого кода в том, что его в
> качестве вопроса привёл деби.Нет, там есть проблема, ваш коллега, кстати, ее нашел.
Берите пример с него.
>Проблемы я тут не вижу, кроме того что деструктор объявлен виртуальным почем зря, только памяти лишней таблица виртуальных функций немножко съест - но я бы не считал это проблемой.А это проблема и проблема серьезная.
>немножко съестМножко. Проверьте сами через sizeof() И главное теряется основное преимущество С++ перед остальными ООП языками:
class A{int x};
sizeof(A) == sizeof(int);
Это проблема настолько серьезная, что в STL виртуальные деструкторы не используются нигде. Вообще.
Да, +1 бал Rob Pike.
Arisu... дадим ему еще один шанс.
> Множко.Этак мы можем долго спорить в таких терминах.
> И главное теряется основное преимущество С++ перед остальными ООП языками:
> class A{int x};
> sizeof(A) == sizeof(int);
> Это проблема настолько серьезная, что в STL виртуальные деструкторы не используются нигде. ВообщеОх.
Вы что, серьезно полагаете это преимуществом? Основным? Перед всеми остальными ОО-языками?!
И вы готовы это свойство реально использовать в своём коде? На трезвую голову?STL вроде бы не рассчитывалась никогда на наследование, вот и не используются - причем тут это-то?
неужели есть надежда на какой-то серьёзный ответ? это же обычная макака.
>Ох.Вы что, серьезно полагаете это преимуществом? Основным? Перед всеми остальными ОО-языками?!Все знают что С++ "быстрый" А откуда берется эта быстрота? А оттуда. Доступ к полям объекта через адресную арифметику (3-5 инструкций процессора) против разыменования и/или таблицы (от 5 инструкций и до бесконечности). Вообще, отказ от разименований в пользу адресной арифметики без потери инструментария ООП и есть вся суть С++. В остальных языках или то или другое. STL целиком и полностью построен на этом.
>И вы готовы это свойство реально использовать в своём коде? На трезвую голову?
Простой пример, парсинг бинарного файла.
С++ - спроецировал файл в память, установил указатель. Все. Почему? Плотная упаковка объектов.
java - печальная история.
>STL вроде бы не рассчитывалась никогда на наследованиеА почему? Продолжайте идею.
Ох. arisu-то был прав.> Все знают что С++ "быстрый" А откуда берется эта быстрота? А оттуда.
Нет, не оттуда. Берется она преимущественно из ручного управления памятью, иммутабельности структур данных и аккуратной, кропотливой и весьма error-prone работы вообще, на довольно низком уровне. За что приходится расплачиваться либо постоянными закатами солнца вручную, либо своим лиспом из темплейтов в каждой мало-мальски большой программме. А чаще всего и тем и другим одновременно. И получается в не самых умелых руках часто медленней (в смысле скорости работы результирующего продукта) чем у более вменяемых альтернатив - от JVM и .Net до LuaJIT.
А адресную арифметику при доступе к полям вам заинлайнят так что и джампов не останется.
> парсинг бинарного файла.
> С++ - спроецировал файл в память, установил указатель. ВсеНет, это только начало. Прелюдия, которую вообще можно опустить за неважностью.
А дальше, в случае хоть сколько-то более сложного формата чем "много чисел по 4 байта" вы начнете прыгать вашим указателем вперед и назад на самые разные расстояния. Отчего современный процессор будет только и делать что кэши инвалидировать и в ОЗУ бегать, а предсказатель переходов - биться об стенку головой от осознания собственной бесполезности.
Либо изобретать на темплейтах свою реализацию парсер-комбинаторов и свой же оптимизатор к ним, чтоб хоть как-то это дело всё-таки выровнять. И отлаживать это еще месяц.> >STL вроде бы не рассчитывалась никогда на наследование
> А почему? Продолжайте идею.Потому что полиморфизм там статический, и прикручена она Степановым, проклинающим наследование в частности и ООП вообще к С++ сбоку изолентой.
>иммутабельностимутабельности, разумеется
>кропотливой и весьма error-prone работы вообще, на довольно низком уровнеВот пример такой работы:
Point A(0,0);
Поздравляем! Вы создали объект на стеке. В большинстве "вменяемых альтернатив" на стеке создается только ссылка, а сам объект размещается в более медленной куче. В более это на два порядка.
Еще пример кропотливой и весьма error-prone работы:
Point A[10];
Поздравляем! Вы создали непрерывный массив из 10 элементов со временем доступа О(1).
В большинстве "вменяемых альтернатив" вместо него linked list со временем доступа O(n).
В особо "вменяемых альтернативах" объекты представляют собой hash таблицы и время доступа к полю объекта в массиве составляет O(n^2)
>А адресную арифметику при доступе к полям вам заинлайнят так что и джампов не останется.В приведенных вами "вменяемых альтернативах" это не работает. Поздравляем!
>А дальше, в случае хоть сколько-то более сложного формата чем "много чисел по 4 байта" вы начнете прыгать вашим указателем вперед и назад на самые разные расстояния.
В "вменяемых альтернативах" мы читаем файл побайтово и пытаемся десерелиазовать байты в типы. Давайте меняться? Вы мне парсер типа файла Х на "вменяемых" языках я вам 20 на невменяемых.
>Потому что полиморфизм там статический, и прикручена она Степановым, проклинающим наследование в частности и ООП вообще к С++ сбоку изолентой.Вы раскрыли страшный заговор. Поздравляем!
А если серьезно, то как насчет выслушать его собственное мнение? Он до сих пор дает лекции по С++. Вот последние http://www.youtube.com/channel/UCYEYhkwzNWRsUkTCpTmChCg
> В большинстве "вменяемых альтернатив" вместо него linked list со временем доступа O(n).Отдельные утырки даже какое-нибудь число умудряются как объект записать. В результате в несколько раз нагибается даже самая простая математика. Которая, теоретически, могла бы быть 1 регистровой операцией. А практически - будет жутким кошмаром.
> Отдельные утырки даже какое-нибудь число умудряются как объект записать.LuaJIT, например. расскажи, как там «нагибается математика».
Тут уместно упомянуть (в хорошем смысле) GSL Shell и Torch7>Torch is a numerical/scientific computing extension of LuaJIT with an ML/neural net library on top. Torch7 is what is being used for deep learning R&D at NYU, at Facebook AI Research, at Deep Mind, and at Google Brain.
> Вот пример такой работы: Point A(0,0);Отличная работа. Теперь а) посмотрите что из этого сделал современный компилятор для современного процессора; б) создайте пару миллионов таких объектов, передайте привет вашему стеку.
А если серьезно, то обсуждать экономию пяти наносекунд в микробенчмарке с бесконечным циклом - занятие столь же утомительное сколь и малопродуктивное.> В большинстве "вменяемых альтернатив" на стеке создается только ссылка, а сам объект размещается в более медленной куче. В более это на два порядка.
Это очень страшно выглядит только пока вы остаетесь в плену стереотипов Си-мышления образца 1970 года. Примерно по этой же причине вас в LISP и Scheme пугают скобочки - потому что вы помните что в Си такое количество скобочек означает дикую лапшу, а не сами по себе.
>The first thing to understand about OCaml is that allocation, in particular short-lived allocations, are much cheaper than you're used to from languages like C# and Java --- allocating a block on the minor heap requires only three instructions, and collection of those objects is very inexpensive if they don't survive to move to the major heap. So the need to allocate lots of short-lived objects is less of a concern than you'd naively imagine.
>That said, if you want to build very high-throughput applications that can process millions of transactions a second, you to need to avoid allocation, particularly long-lived allocations that end up on the major heap. Jane Street's Core library (which is used throughout Real World OCaml) provides tools for creating pooled objects for just this kind of use-case.
>http://www.infoq.com/articles/real-world-ocaml-interview
>В большинстве "вменяемых альтернатив" вместо него linked list со временем доступа O(n).
>В особо "вменяемых альтернативах" объекты представляют собой hash таблицы и время доступа к полю объекта в массиве составляет O(n^2)Сложно угадать о каких именно существующих в вашем воображении альтернативах вы говорите. Может быть, о Javascript? Давайте о чем-нибудь менее удобном для избиения и более вменяемом, о том же OCamle, например.
>В приведенных вами "вменяемых альтернативах" это не работает.
Но воображение у вас хорошее. Чего о памяти, к сожалению, не скажешь.
>В "вменяемых альтернативах" мы читаем файл побайтово и пытаемся десерелиазовать байты в типы. Давайте меняться? Вы мне парсер типа файла Х на "вменяемых" языках я вам 20 на невменяемых.
Давайте. Вот вам парсер - https://code.google.com/p/bitstring/source/browse/trunk/exam...
С вас такой же на С++, без include pcap.h, разумеется - это ведь просто пример.
Формат здесь - http://wiki.wireshark.org/Development/LibpcapFileFormatПотом сравните скорость работы, задумайтесь, сделайте выводы самостоятельно.
Для разминки можете сделать простое упражнение - написать на Си разбор простейшего формата - 6 битный счетчик n, за ним - целое число размером n бит (битов в нём может быть от 1 до 64)
На OCaml это выглядит так:
>let bits = Bitstring.bitstring_of_file "input.data" in
>bitmatch bits with
>| { n : 6;
> data : n+1 } -> dataБиблиотека очень простая, в Си вынесен кусочек с полутора маленькими fastpath-частными случаями.
В качестве более общего примера можете посмотреть сюда - http://www.ffconsultancy.com/languages/ray_tracer/comparison...
(задумчиво) на D я бы взял структуры и быстро накидал бы генератор кода на шаблонной магии. сгенерированому коду, в принципе, достаточно простейшего input range. ну, или добавить небольшую оптимизацию на случай индексируемых ranges, и тогда при использовании какого-нибудь mmap получаем вовсе zero-copy.ну, и заодно получили «наколенный», но вполне универсальный десериализатор, который адаптируется к возможным сменам формата, которые не требуют сложных циклов и условий, просто при помощи изменения тел struct{}. а к более сложным — таки ещё и немного допилкой кода.
цпп, конечно, тоже такое позволяет, но настолько через анус, что лучше даже не пробовать, а честно карябать весь boilerplate руками. заодно затачивая его под работу с куском памяти, а то ranges там… ну, не очень удобно применять.
Я программирую в том числе для микроконтреллеров pic.
среди pic есть pic32 который использует систему команд mips32 r2.
почитайте о ней - смею Вас заверить, что там далеко не 5 команд.
там есть и кеш, и префетчер и dma, и чего только душе угодно.
+по поводу С - С довольно редко бывает чистым - почти наверняка часть кода один дьявол будет выброшена в платформозависимые и реализована на ассемблере.
я не говорю про DMA, интерфейсы ядер и все что с этим связано.
Си и плюсы годятся чтобы писать чуму на уровне ядра.
Питон же несравнимо медленней и преследует цели совершенно другие.
Сомнительно, что вообще хоть как-то можно сравнивать эти языки.
> Я программирую в том числе для микроконтреллеров pic.
> среди pic есть pic32 который использует систему команд mips32 r2.
> почитайте о ней - смею Вас заверить, что там далеко не 5
> команд.Assembler всё равно очень простой язык, наверное самый простой, только разработка на нём бесконечно долга.
> Assembler всё равно очень простой язык, наверное самый простой, только разработка на
> нём бесконечно долга.Assembler это программа. Вы путаете с ее с "языком ассемблера".
Но все равно заявление "Assembler всё равно очень простой язык, наверное самый простой" совершенно неверно.
Вот ознакомтесь - настольная книга разработчика на ассеблере "Intel® 64 and IA-32 Architectures Software Developer’s Manual"
988 страниц.
том 3.
часть b.
http://css.csail.mit.edu/6.858/2011/readings/ia32/ia32-3b.pdf
Спецификация конкретного ассемблера например nasm не намного короче.
Вы путаете сложность аппаратной архитектуры со сложностью языка программирования
> Вы путаете сложность аппаратной архитектуры со сложностью языка программированияВ случае ассемблера эти понятия пересекаются. Инструкции для каждой архитектуры свои.
> В случае ассемблера эти понятия пересекаются. Инструкции для каждой архитектуры свои.Можете использовать только несколько простых инструкций, никто не заставляет использовать весь набор. Эффективность конечно просядет, т.к. вы не использовали все фичи архитектуры, но это уже второй вопрос.
Я ничего не путаю. Для языка ассемблера характерно отсутствие* уровня абстракции над аппаратной архитектурой. Вот про MOVD MM0,EAX что скажете?
* если не обращать внимание на специфичные расширения и макросы конкретного асемблера.
> Я ничего не путаю. Для языка ассемблера характерно отсутствие* уровня абстракции над
> аппаратной архитектурой.Совершенно необязательно именно над аппаратной.
Если о MSIL можно спорить, то DynASM - именно ассемблер, просто довольно продвинутый.
Собственно, во времена когда на ассемблерах писались миллионы слов в год, использовались довольно мощные макроассемеблеры, скорее похожие на DynASM, а не тупые трансляторы mov-ов в опкоды процессора.
Ну и какой ассемблер способен абстрагироваться от приведенной выше MOVD MM0,EAX в контексте процессоров ARM, у которых нет ни MM0, ни EAX?
Да тот же DynASM.ADDVN -> ARM: http://www.reddit.com/r/programming/comments/hkzg8/author_of.../
ADDVN -> x86 (SSE2): http://www.reddit.com/r/programming/comments/badl2/luajit_2_...
> довольно мощные макроассемеблеры,Так они и сейчас такими остались. То что они могут до кучи транслировать MOV в опкоды - не отменяет того что там макросы. А в вещах типа диревтивы asm - еще и неплохая интеграция с си.
>> Я программирую в том числе для микроконтреллеров pic.
>> среди pic есть pic32 который использует систему команд mips32 r2.
>> почитайте о ней - смею Вас заверить, что там далеко не 5
>> команд.
> Assembler всё равно очень простой язык, наверное самый простой, только разработка на
> нём бесконечно долга.Ну да, если считать его набором библиотечных функций, всё кроме сравнения - вызов функции... :)
> Assembler всё равно очень простой язык, наверное самый простой,LISP проще.
Кстати, поинтересуйтесь откуда взялись car и cdr.> только разработка на нём бесконечно долга.
Поэтому придумали макроассемблеры и препроцессоры.
> LISP проще.Синтаксис у него мерзотный, так что иной раз программу на ассемблере читать проще. По крайней мере там не вывихнешь мозг, глядя на 10 скобок в ряд.
>Синтаксис у него мерзотный,У ЛИСПа нет синтаксиса. Вы либо не знаете что такое ЛИСП, либо не знаете что такое синтаксис языка программирования.
Кстати ЛИСП единственный язык, на данный момент, который был написан изначально сам на себе.
Первая версия eval была реализована на ЛИСПе на бумаге, потом вручную преобразована в исполняемые машинные коды. Для сравнения создатели импотента-Ruby не смогли даже собственную стандартную библиотеку языка реализовать полностью на ruby.
> У ЛИСПа нет синтаксиса. Вы либо не знаете что такое ЛИСП, либо не знаете что такое
> синтаксис языка программирования.Грубо говоря, мне не нравится как на этом выглядят типичные программы - их читаемовть в ж...е. А сам себе весь синтаксис кроить я как-то поленюсь. Примерно как поленюсь сам себе писать всю операционку, например.
> в исполняемые машинные коды. Для сравнения создатели импотента-Ruby не смогли даже
> собственную стандартную библиотеку языка реализовать полностью на ruby./me считает невозможность бутстрапнуться (нет, я не про долбаную библиотеку от твиттера) достаточно характерным индикатором.
Да, как-то так получается что уважающие себя операционки разрабатываются под самими собой. Уважающие себя компилеры - собирают себя сами, и рантайм не забывают. А если для сборки компилера или ЯПа нужен другой компилер или ЯП - возникают нехорошие подозрения в адрес такого ЯПа...
> А если для сборки компилера или ЯПа нужен другой компилер или
> ЯП - возникают нехорошие подозрения в адрес такого ЯПа...мда… компилятор си из gcc — отстой, без c++ не собирается. clang — ещё больший отстой, само собой, там вообще сплошной c++. конечно, это обозначает, что си — очень плохой ЯП. не так ли?
> мда… компилятор си из gcc — oтcтoй, без c++ не собирается. clang
> — ещё больший oтcтой, само собой, там вообще сплошной c++.Я их просто рассматриваю как один набор утилсов и части одной и той же софтины. И кстати gcc до 4.7.х собирается сями, без плюсов. Потом - смесь из сей и плюсов. По твоей логике получается что oтcтойность варьируется по версии, принимая дробные значения :)
> конечно, это обозначает, что си — очень плохой ЯП. не так ли?
Скорее, в данном случае это обозначает что большие проекты на плюсах лучше получаются.
> Скорее, в данном случае это обозначает что большие проекты на плюсах лучше
> получаются.захватившая весь мир BeOS снисходительно смотрит на маргинальный Linux.
> Я их просто рассматриваю как один набор утилсов и части одной и
> той же софтины.нененене, вилять не надо. компилятор си из состава gcc не может сам себя собрать? не может. всё, отстой.
> /me считает невозможность бутстрапнуться (нет, я не про долбаную библиотеку от твиттера)
> достаточно характерным индикатором.А если головой подумать? В чем смысл того бутстрапа в 2014 году, а не 40 лет назад когда каждый новый компьютер был ни с чем не совместим?
> А если головой подумать? В чем смысл того бутстрапа в 2014 году,
> а не 40 лет назад когда каждый новый компьютер был ни с чем не совместим?Смысл в том что если некия ЯП даже сам себя не обслуживает - он это... инвалид, чтоли.
> Смысл в том что если некия ЯП даже сам себя не обслуживает
> - он это... инвалид, чтоли.нет. умственные инвалиды — это те, которые тратят кучу усилий на то, чтобы сделать «компилятор себя на себе» при наличии уже существующего компилятора «не на себе». если, конечно, это не окупается в итоге какими-то МЕГАПРОФИТАМИ в виде существенного увеличения скорости компиляции. или существенного улучшения качества кода. или ещё чего-нибудь такого же весомого. в общем, необходимое условие: новый компилятор должен быть как минимум не хуже существующего. достаточное — иметь вдобавок заметное улучшение.
> МЕГАПРОФИТАМИ в виде существенного увеличения скорости компиляции. или существенного
> улучшения качества кода. или ещё чего-нибудь такого же весомого.Например, то, что компилятор, написанный на компилируемом языке, это в определённом смысле набор тестов для себя же. Не очень хороший, но, тем не менее. А вот смысла писать окончательный (не bootstrup) компилятор Go на языке Цэ я что-то не вижу.
> А вот смысла писать окончательный (не bootstrup) компилятор Go на
> языке Цэ я что-то не вижу.а я вижу. например, для встраивания в gcc так удобней. для портирования на новые архитектуры, где есть только си — удобней. кстати, для отсутствия забега по граблям («ой, а это ошибка в компиляторе или в компиляторе?») — тоже удобней.
ну питон ладно. Все начинали обучения с бейсика. ничего не изменилось, ибо питон - его диалект. Сильно ушедший от прародителя видимо во избежании патентных принтензий со стороны M$ :)Очень заинтересовал "язык" на третьем месте графика. И ведь он популярнее C и CPP! А я вот как оказалось его вообще не знаю. Ни буковки. Стало стыдно.
> бейсика
> патентных принтензий со стороны M$Ага, а инет Билл Гейтс изобрёл.
Ты правилами русского языка пренебрегаешь, чтобы избежать патентных претензий от Розенталя?
>> бейсика
>> патентных принтензий со стороны M$
> Ага, а инет Билл Гейтс изобрёл.
> Ты правилами русского языка пренебрегаешь, чтобы избежать патентных претензий от Розенталя?Я не очень старался их соблюдать :).
А что именно кроме опечаток так режет глаз? Отсутствие запятых?
> А что именно кроме опечаток так режет глаз? Отсутствие запятых?Нехватка знаков препинания, первое предложение с маленькой буквы, "начинали обучениЯ", "во избежаниИ патентных прИнтензий".
> прИнтензийпрИНтензий, вы хотели сказать ;)
Давайте вы будете говорить только за себя. Лично я начинал не с бейсика.
Отличный язык со строгим синтаксисом и большим количеством библиотек на все случаи жизни. Если бы в нём ещё поддерживали обратную совместимость хотя бы между минорными релизами - цены бы ему не было.
> Отличный язык со строгим синтаксисом и большим количеством библиотек на все случаи
> жизни. Если бы в нём ещё поддерживали обратную совместимость хотя бы
> между минорными релизами - цены бы ему не было.Она хуже минорной совместимости в ПЫХе?
> Отличный язык со строгим синтаксисомОтличный. От других.
Точно нужно идти куда-то в универ его изучать. Что-то до меня простейшее дойти не может. Хочу на Termux установить Python, смотрел тут https://codeby.net/threads/termux-python3.67521/ как это правильно сделать и всё равно не получилось ))))
