• Изучаем английский: Пять неочевидных письменных ошибок, и как их избежать
    0
    С таким значением не встречался, а john в смысле толчок, не очень ухоженное отхожее место в штатах широко используют как в разговорах, так и в литературе. Кстати, в культовом монтипитонном фильме Бразилия есть эффектный момент с использованием слова willy — знатоки питона должны знать. :)
  • Изучаем английский: Пять неочевидных письменных ошибок, и как их избежать
    0
    Можно предположить, что это такой тонкий американский юмор, такая аллюзия на типовой британский характер, Джона Буля. Англичане это слово не используют. Что касается Дика, то они это называют также willy или peter. Кстати, если что-то даже вполне обычное как-то некстати закончилось, то можно красиво сказать to peter out, например, The hot water always peters out in the middle of my shower — горячая вода всегда кончается, если я принимаю душ.
  • Изучаем английский: Пять неочевидных письменных ошибок, и как их избежать
    0
    john c маленькой означает туалет, например, Where is a john?
  • Умные часы с Бейсиком на физическом 6502
    +1
    Интересно, сможет ли работать с батарейкой?
  • Using Linux Kernel Sequence Files
  • Грамматика английского. Who vs. Whom – как понять, какое слово использовать
    0
    Нормальные британцы «хум» в разговорной речи почти не используют.
  • Как я пишу конспекты по математике на LaTeX в Vim
    0
    Тут почти всё от преподавателя зависит, а во многих вузах, к сожалению, значительная часть студентов более того, чтобы законспектировать и не думает, хотя Латех — это не для них, конечно.
  • Читай старьё
    +1
    Нашел книжку, купил электронную за 100 рублей, прочитал, понравилось, заказал бумажную, 100 рублей вычли из итоговой стоимости.

    Извинит, но зачем нужна бумажная, если только не на подарок под старину?
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    К сожалению, прологом сейчас практически не занимаюсь. Но посмотрите страничку в википедии: Watson — очень серьёзная система и работает в штатном Линуксе. Там же приводится цитата: «We required a language in which we could conveniently express pattern matching rules over the parse trees and other annotations (such as named entity recognition results), and a technology that could execute these rules very efficiently. We found that Prolog was the ideal choice for the language due to its simplicity and expressiveness.» Pазработка компиляторов с использованием пролога имеет несколько неоспоримых достоинств. Погуглите prolog projects и обнаружите десятки развивающихся систем программирования, основанных на идеях пролога. Аналогично, prolog deep learning. Если вы проведете подобные изыскания по аде, коболу, эйфелю и др. не самым распиаренным языкам, то найдёте, что у пролога всё относительно неплохо. Предположу, если кто ищет себе комфортабельный вагончик, то пролог пока ещё до этого не созрел. А тому кто хочет быть локомотивом, пролог предоставляет огромное и очень перспективное поле для деятельности.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    Довольно много проектов, связанных с машинным обучением с использованием обучаемых сетей. Также есть проекты для работы с естественным языком. Всего тут довольно много и меньше не становится. Почему процент пролог-проектов в целом небольшой? Возможно потому, что сложилась некая культура программирования на С-подобных языках (возьмем, например, APL, оберон, аду или эйфель — их тоже не больше, а скорее меньше, чем пролога), к которой привыкли и которая пока адекватна решаемым задачам. Пролог требует специальной подготовки, которой нет у многих топовых специалистов. В самом прологе не хватает многих отточенных на типовые задачи механизмов, которые появятся только, если сделать его очень популярным. Вокруг специального железа для пролога какой-то туман, возможно секретности. И, могу предположить, что широкое внедрение пролога сделает большинство ЯП устаревшими, к этому пока не готовы.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    Он может быть и будущее, но на данный момент он все равно бесполезен на практике.

    Не могу с таким согласиться. Существует достаточно много перспективных проектов вокруг пролога. Пролог — универсальный язык и на нём можно делать всё, что, например, на питоне. Может просто нужен кто-нибудь типа Гвидо, который сделает популярный вариант пролога. Скорость работы хороших прологов на уровне языков сценариев. Мне кажется полезность-перспективность и текущая массовая популярность — это разные вещи. Мое мнение — пролог это один из самых простых и близких к естественному языков программирования. К сожалению, приходится до сих пор больше работать сo скорее с потомками фортрана. :(
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    3ря вы так. Пролог или какое-то его удачное расширение — это будущее программирования. Пролог это почти 100% математика, тогда как другие языки — это смесь математики и отсебятены.
    Вы похоже склоняетесь к точке зрения оппонента, что декларативность гарантирует поиск результата. Но это так только в случае действительно 100% точного описания задачи. Порядок дизъюнктов — это один из элементов такой точности.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    –2
    Вам привели пример, что описание задачи может приводить к разным результатам. И ваш пример о том же. А вы что хотите, чтобы машина ещё и знала, что Вам нужны предки библейских персонажей немедленно, а не её усердная работа по их поиску на миллионы лет? Хотеть не вредно. Но лучше давать машине уточнения в таких случаях. В прологе такие уточнения — это, в частности, порядок дизъюнктов и предикатов в них. Предлагаю учить пролог и yчить тщательно!
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    –1
    Если вам нужна теория для её самой, то разницы о очередности нет, а если вы что-то хотите от теoрии практического, то есть. Это и отражается в прологе, как в практическом инструменте. Если кто-то останется без головы, то приз получать уже будет никому. Декларативность предполагает обычно слишком много вариантов и зацикливание — это тоже вариант. От перемены местами дизъюнктов в вашем примере вы его и получаете. В 90-е кто-то предлагал вариант пролога с со случайным выбором — интересный подход, но, полагаю, что он сильно понижает производительность работы. Кому нужен ответ, полученный через 100 лет? Получается выбор: 1) изобретать замысловатые системы логики, конкурировать с Аристотелем; 2) пытаться сделать эффективные машины логического вывода — это пролог, SQL, скорее неудачный и несостоявшийся меркурий,…
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    –1
    Если вы хотите сделать что-то с практическими результатами, вам придется разбираться с порядком применения правил — равноправия на практике обычно не получится. Перепишите мой пример в виде «налево — потеряешь голову» ИЛИ «направо — получишь приз» — какая тут императивность, 100% декларативность, но от того, за что вы возьметесь в первую очередь, зависит результат.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    Это пример практической некоммутативности связки ИЛИ. Например, выбор на дороге: 1) налево — потеряешь голову, 2) направо — получишь приз. От того какой путь выбрать первым зависит как пойдут дела. :) Так и и пролог. Проблема не в нем, а в природе логики.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    0
    Неновые языки тоже иногда задают очень непростую связь с peaльнocтью. Например, на языке APL согласно википедии всего в одну строчку можно напиcать игpу Жизнь Kонвeя — life←{↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵} — нечто.
    Язык TeX, будучи универсальным, порождает весьма интересные кoды даже для самых простых задач, например, расчета чисел Фибоначчи.
  • Новые языки программирования незаметно убивают нашу связь с реальностью
    +1
    Вроде бы должно быть каждому понятно, что из описания нетривиальной задачи её эффективное решение не следует. Или, например, что связки И/ИЛИ на практике не коммутативны.
  • Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х
    0
    > А в выхлопе современных компиляторов, если вы найдёте использование регистров типа ah, bh, то это специальные готовые вставки на редчайшие особые случаи.
    Это не так. Вот пример кода, где GCC генерирует использование второго байта регистра, например, BH.
    char c;
    register union {
    int a;
    char b[4];
    } a;
    c = a.b[1];
    Есть результат: x86 — самые быстрые и с лучшим ПО (Linux на x86 также лучший) — всё остальное лирика. Поклоники VAX очень их и ARM не любят — сломали их малину. Когда-то и восстания луддитов были.:) ARM сейчас лучше только по энергопотреблению. Если бы у Acorn когда-то был посильнее менеджмент, то у них был шанс опрокинуть x86. Когда-то они также в СССР позорно проиграли с ICL 1900 в пользу IBM/360 — у нас решили лучше у американцев воровать, чем с честными англичанами иметь дело — нашли подход к «загадочной» русской душе. :) ARM-64 как и RISC-V какой-то более выхолощенный — не догнать с этим x86. Повторю, современный ARM развивается с оглядкой на Intel.
  • Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х
    0
    Это я неудачный пример взял, наспех. Там нужна константа более 255, а не 5. Со сложением как раз проблем (почти?) никогда нет — продумали они тут неплохо. Проблема в знаковом расширении, которое иногда сильно всё запутывает, например, при работе с таблицами. И, конечно, BISB, а не ORB. :) В PDP-11 ассемблере много хорошего и сделали его ещё в 60-х!
  • Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х
    0
    x86 до сих пор в лидерах и частично потому, что более гибко, чем многие другие архитектуры умеет работать с байтами. 3ачем им быть на что-то ещё похожими? Сравните, например, 8086 и 68000. У ARM-32 встоенный в почти каждую команду barrel shifter, который даёт мгновенный доступ к каждому байту слова. У ARM-64 с этим хуже и, возможно, что так Intel ослабляет конкуренцию c x86. ARM смог перегнать х86 в 80-х и в 1996. После второго успеха Intel просто купила эту технологию и стала во-многом её определять.
  • Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х
    0
    Eщё пример вспомнил про неуклюжесть PDP-11 с байтами. Нужно считать байт из памяти и добавить к нему, например, 5. Число в памяти целое беззнаковое, может быть более 127. Самое лучшее, что придумал, — это CLR R1; ORB mem,R1; ADD data,R1
  • Эмоциональная история процессоров для первых компьютеров с 70-х до начала 90-х
    0
    [6502] С фортом это не я придумал, так лучшие в мире 6502-программисты решили. Можете посмотреть конкретные коды по ссылке (там можно поискать слово fetch).
    [PDP-11] Рассмотрим, например, CMPB #2,R1. Для байтовой константы 2 будет выделено слово (а не байт) и так будет верно для всех операций с байтовыми константами. В самом ассемблере неуклюжести это не вызывает, но если смотреть на машинные коды, то лишний 0 — это как пятое колесо. И когда памяти так мало, всего 32КБ — этот ноль чувствуется сильно. Не получится ещё без неуклюжести сравнить старший байт R1 с той же 2.
  • Q2VKPT: полностью переписанный Quake II с реалистичным освещением
    0
    Найти бы время и пройти опять…
  • Как научить людей использовать Git
    0
    Промежуточные коммиты? Но они же все равно потом пойдут в общий репозиторий, если это коммиты, а не сташи. Штучек, ломающих репозитории, ради поправок в «неправильных» коммитах немало везде. Извините, но у меня представление такое, если не работает сервер, то это в 99% случаях не работает сеть. Никакой нормальной работы сегодня или даже 5 лет назад без сети не представить. Но если случится 1%, когда именно просел на часок-другой только сервер, и очень хочется сделать коммит, то из-за редкостной диковинности такой ситуации можно чуть-чуть побольше сделать, а именно скопировать каталог для его дальнейшей отправки на сервер, когда тот заработает, — неудобство, но редкое и незначительное. GIT интересный инструмент, действительно, учитывающий очень много тонкостей, но это не значит, что другие VCS как-то хуже, они — другие. DVCS реально повышают надежность, особенно больших проектов типа ядра Linux и это очень существенно, но есть и другие способы повышать надёжность.
  • Как научить людей использовать Git
    0
    Извиняюсь за неточность, имел в виду, не используйте pull без --rebase. Перебазировка устаняет лишние, технические коммиты.
  • Как научить людей использовать Git
    0
    SVN — удобнее, а rebase в GIT штука очень полезная, рекомендую её использовать всегда и забыть про merge.
  • Как научить людей использовать Git
    +2
    Работал с ними и в нашем проекте они были скорее для создания искусственного трения между разработчиками. Без них работа получалась бы быстрее.
  • Как научить людей использовать Git
    +1
    Можете попробовать Mercurial. Oн внешне, для пользователя почти как Subversion, а внутренне это почти GIT. Разницы особой не заметите, но это будет DVCS. Кому-то нравится мыло, а кому-то шило. :)
  • Как научить людей использовать Git
    –5
    Если git-сервер рухнет, командная работа с git упадет и никакие локальные коммиты не помогут. Единственное достоинство git и др. распределенных систем в том, что если сервер упадёт навсегда (хотя обычно такое абсолютно невозможно), то будет возможность многое восстановить на возрожденном сервере. А главный недостаток и так все знают — много всяких замороченностей ради возможности иметь упомянутое выше достоинство. А если вы работаете в одиночку, то, имея сервер на своем компьютере, разницы между git/hg/… и svn/cvs/… вообще не найдете, кроме больших заморочек с первыми.
  • Один гигантский шаг для машины, играющей в шахматы
    0
    Повара уже на подходе — — неуклюжие ещё, но это только начало. И что вы нашли нехорошего? Изобретать новых роботов — это не обязанность. :)
  • Мой компилятор Паскаля и польское современное искусство
    0
    Есть ещё вроде бы неплохой паскаль — pascalabc.net/ru
  • Мой компилятор Паскаля и польское современное искусство
    0
    Вспомнилась история, близкая к теме. Будучи студентом ВМК МГУ подрабатывал в 1990 в ЦНТТМ Университет и там встретился с молодым человеком, который с его слов сделал портирование турбо-паскаля для MS-DOS версии 4.0 на отечественный компьютер Корвет на базе процессора Intel 8080. Работа по моим представлениям более чем колоссальная. И он хотел за свою работу некоторый гонорар, в чём, подозреваю, не преуспел. К сожалению, похоже эта работа так нигде до сих пор и не представлена. :(
  • Один гигантский шаг для машины, играющей в шахматы
    –2
    С такими программами возможно скоро появятся и роботы, которые будут убираться, готовить пищу, строить дома,… Человеку останется только это потреблять и изобретать новых роботов.
  • Мой компилятор Паскаля и польское современное искусство
    +1
    В ВМК МГУ делать компилятор упрощенного паскаля — это была курсовая работа на рефале. И неужели ваш компилятор не портировали в мир Коммодора 64?
  • Python становится самым популярным языком программирования в мире
    0
    Паскалить массово в школах стали прекращать с начала 90-х, потому как паскаль почему-то перестали поддерживать — как в сказке, как будто кто-то произнес волшебное заклинание и всё переключилось на яву. Но МГУ ВМК вроде до сих с паскалем дружит. Язык сам кое в чём до сих пор лучший. Учит абстрактно относится к данным, а не утилитаристично как с питоном или рубином, с множествами работать математически, а не по-программистки,… Поколение паскальщиков до сих пор во многом поддерживает Дельфи. Потом пошла система питон-ява, что и даёт нынешние несколько завешенные пики по этим языкам. Хотя и питон и ява очень даже достойные продукты. Но мне, например, Ruby предпочтительнее, чем Python.
  • Python становится самым популярным языком программирования в мире
    0
    Интересно, это где так?
  • Python становится самым популярным языком программирования в мире
    +1
    Никто не упоминает факта, что в школах за рубежом для обучения программированию используют почти исключительно питон. Пока это сохраняется, популярность будет сохраняться несколько завышенной по отношению к качеству языка.
  • Все лунные растения погибли
    0
    Они не на обратной, они на дальней — en.wikipedia.org/wiki/Far_side_of_the_Moon
  • Hello world! Или англоязычный Хабр, v1.0
    0
    Признаюсь, немецкий знаю на уровне отдельных фраз, хотя с числами знаком — не удивили. Если вы внимательнее прочитаете мои комментарии, то обнаружите, что главный постулат, который отстаиваю в том, что все языки развитых культур достойны друг друга, так как способны адекватно удовлетворять требования этих культур. Английский считаю более сложным поскольку он удовлетворяет совокупные потребности многих культур, чья совокупность сложнее совокупности культур, использующих русский. Сложности возникают, когда в одном языке есть конструкции, которых нет в другом. Насчет пословного перевода с английского — это верно только для упрощенного перевода несложных текстов. В английском слишком много корней, например, как переводить gleam-glint-glister-glitter на русский? Поблескивает, блестит, отсвечивает или ещё как-то? Каждое слово имеет свой оттенок, который в русском подобрать можно часто только в словосочетаниях и при глубоком изучении контекста. А кривой перевод сложных текстов — это что-то будет кошмарное, попробуйте гуглом что-то реально сложное перевести, хотя гугл это существенно более продвинутая система, чем просто пословный перевод. Для примера грамматическо-семантических сложностей попробуйте попереводить шутки типа «тук-тук!», «кто там?» :) Тут ещё кому-то про Владимира Набокова писал — можете найти поиском.