Программирование *

Прочитав про IP-стэк twIP, который помещается в размер твита и отвечает на пинги, корейский программист Канг Сеонгхун (Kang Seonghoon) решил создать нечто такое же миниатюрное и при этом работоспособное. И он создал самый маленький интерпретатор Brainfuck на C размером всего 160 байт.

s[99],*r=s,*d,c;main(a,b){char*v=1[d=b];for(;c=*v++%93;)for(b=c&2,b=c%7?a&&(c&17?c&1?(*r+=b-1):(r+=b-1):syscall(4-!b,b,r,1),0):v;b&&c|a**r;v=d)main(!c,&a);d=v;}

Перевод третьей лекции из курса «Структура интерпретация компьютерных программ».

Это самый известный курс по программированию за последние 25 лет; с 1980г читается в MIT, а с недавних пор что-то подобное читается и в Беркли.

Курс сменил преподавателей и даже язык программирования Scheme на Python(на мой взгляд совершенно зря) и тем не менее информация, которая дается в этом курсе остается архи актуальной в любое время. Я бы сравнил этот курс с чем-то очень фундаментальным и важным для программистов, типа математики или теории алгоритмов.

Мне бы очень хотелось, чтобы программирование у нас в стране преподавалось таким вот образом.

Приятного просмотра!

В прошлый раз мы ограничились компиляцией джей-скрипа в файл в нашем собственном формате, которому требовался специальный загрузчик. Кроме того, мы задумали было пару оптимизаций исполнимого кода, требующих анализа соседних команд.

Далее в посте:

1. Оптимизация «в глазок»
2. Стандартные функции
3. Вывод в ELF
4. Как это работает?
5. Что получилось?

Напоминаю, что мы пишем компилятор для игрушечного языка джей-скрип. Начали с компиляции в п-код, потратили немало сил на его оптимизацию, и приготовились к заключительному этапу компиляции — к выводу машинно-зависимого выполнимого кода.
Никаких замысловатых алгоритмов тут уже нет: по большому счёту, только замена одной системы команд на другую.

Далее в посте:

1. Выбор кода
2. Загрузчик
3. Изменения в п-коде
4. Генерация
5. Что получилось?

Удивительно, что до сих пор никому еще не пришла в голову идея перевести эти легендарные лекции на русский язык.

В качестве эксперимента выкладываю перевод первой из 20 лекций. Если это получит должный отклик, буду переводить дальше.

В статье рассматриваются основы разработки программного обеспечения для Nintendo DS под Linux. Впрочем все используемые инструменты кроссплатформенные и не должно быть больших отличий для других ОС.

Для начала разберёмся, что же вообще из себя представляет эта игровая консоль. Вот, что нам говорит википедия:
* Процессор: ARM946E-S — 67 Мгц, сопроцессор ARM7TDMI — 33 МГц
* Память: 4 МБ, 656 КБ видео памяти, 512КБ памяти для текстур
* Экран: два отдельных ЖК-дисплея, диагональ 77 мм (3 дюйма), разрешение 256х192 пикселей, до 260 тысяч цветов. Расстояние между экранами — примерно 21 мм, что эквивалентно 92 «скрытым» строкам.
* Видеосистема: Поддержка 2D и 3D (T&L, преобразование координат текстур, маппинг текстур, альфа-смешивание, сглаживание, цел-шейдинг и Z-буферизация), теоретически позволяет отрисовывать 120 000 полигонов в сек (однако, имеет ограничение на отрисовку 6144 вершин или 2048 треугольников за один кадр).
* Звук: Стерео, 16-канальный ADPCM/PCM
* Накопители: 1 слот для собственных катриджей Nintendo DS, 2 слот для катриджей Nintendo Gameboy Advance
* Связь: IEEE 802.11 (Wi-Fi), для соединения используется собственный формат Nintendo. Радиус локальной сети от 10 до 30 метров в зависимости от условий.
* Управление: сенсорный экран, встроенный микрофон для голосовой идентификации, A/B/X/Y кнопки, D-Pad, шифты L/R, кнопки Start и Select
* Время работы: 6-10 часов
* Вес: 275 грамм
* Размеры: 148,7 × 84,7 × 28,9 мм

File names are infinite in length, where infinity is set to 255 characters.
--Peter Collinson: The Unix File System

Итак, у нас есть программа на п-коде, и в её распоряжении неограниченное количество регистров (т.е. 255). Число регистров у реального процессора куда меньше (предположим, четыре). Что будем делать?

Далее в посте:

1. Разбор п-кода
2. Время жизни
3. Реализация
4. Простые оптимизации
5. Расщепление версий
6. Работа с памятью
7. Что получилось?

Это единственный пост в серии, в центре внимания которого — старообрядный сишный бизон, так надоевший некоторым. Тем, кто пишет не на Си, пост всё равно должен быть интересен, потому что похожие по принципу работы генераторы LR-парсеров существуют для очень многих языков. Тех же, кто идеологически не приемлет LR-парсеры, мне сегодня привлечь нечем.

Далее в посте:

1. Компиляция грамматики
2. Двухступенчатый парсер
3. Что у него внутри?
4. Конфликты в грамматике
5. Как это работает?

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

Первые посты серии уже подготовлены, и бета-тестировались в одном маленьком и наглухо закрытом сообществе. Тем не менее, я буду продолжать их править с учётом пожеланий почтенной хабрапублики.

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Начиная разработчиком на тогда еще сверх продвинутом IDE от компании Borland, bc++ 3.11, работающая в операционной системе DOS, в которой тогда единственное, чего не хватало — так это поддержки dos4gw (который вышел, если мне не изменяет память, парой годами позже), я любил эту IDE и мне казалось, что на ней можно сделать все что угодно. Была куча драйверов, которые писались энтузиастами, меняющие шрифты консоли, кодировку, была целая система работы с памятью… Прорывом были отгружаемые динамически библиотеки на диск, созданные чтобы вмесить все в память. Сегменты (ну, современные программисты, что такое сегменты оперативной памяти, и откуда 640К?), нижняя память, верхняя память… 640 килобайт… Люди придумывали все новые задачи компьютерам, а гении своего дела эти компьютеры придумывали. И ведь на самом-то деле это не так давно было… Это было почти вчера.

Статья без начала, в которой автор рассказывает о невыносимых типажах людей, с которыми он работал за последние 30 лет, с эпилогом переводчика

Я закончил колледж 30 лет назад. Моей первой работой была разработка испытательной аппаратуры для Univac. Это были бы замечательные времена, если бы не…

Грег Скрытный

Здесь я впервые столкнулся с человеком, который считал, что не помогать другим и не отвечать на вопросы — это некая форма гарантии занятости — его занятости.

Однажды я рассказал в общих чертах о проекте, которым я собирался заняться. Грег внимательно выслушал и сказал то же, что и обычно: ничего. Я провозился с реализацией неделю или две, пока не обнаружил, что мой подход в корне неверен. Я спросил об этом Грега, и он ответил, что для него это было очевидно с первого взгляда. Знаете, он ничего не сказал мне! Будь я его боссом, я бы его уволил.

10 вещей, которые никогда не преподаются программистам в вузах.

1. Мы не правы

Программисты зачастую имеют большое эго. Поэтому часто бывает трудно осознать, что мы не правы в чем-то. Я видел много споров относительно архитектуры проектов, где разработчики расхваливают свои идеи. Но, предположим, что мы все неправы. И отличаемся только в степени своих заблуждений.
Очень важно осознать и принять этот факт только один раз и мы будем открыты, чтобы выслушать других и использовать свои идеи, чтобы создать лучшее решение.

Некоторое время назад я натолкнулся на сайт "TheRightTool" — эдакий рейтинг языков программирования на соответствие разным утверждениям, например: «На этом языке легко писать эффективный код». Сразу понятно, что такой рейтинг очень полезен (хотя интерфейс у них — беда — на третьем вопросе мне надоело переставлять языки).

Я попытался на своем блоге дать ссылки на автоперевод, но понятное дело, что он оставляет желать лучшего. Но ведь русские (вполне возможно) больше всех знают о языках программирования! А больше всего программистов на Хабре.

Итак, сегодня в течение часиков пяти мне было заняться нечем, так что, дорогой Хабр, встречай русский аналог (на слабеньком VPS, так что рано или поздно сдохнет под Хабраэффектом — извиняйте, ставьте закладку, заходите завтра):



Надеюсь скоро мы, коллективным 4-хлетним Хабраразумом, узнаем — какие языки для чего можно использовать.

Программист, опыт работы 1 год:
— Нет такой технологии, которую я бы не смог освоить!

Программист, опыт работы 10 лет:
— Нет такой технологии, без которой я бы не смог обойтись…

Представьте себе: ваш племянник спрашивает у вас, сколько будет 2*2+1. Вам не до того, и вы переадресовываете вопрос своему интерпретатору, который честно отвечает: 6. Внимание, вопрос: благодаря какому языку программирования ваш племянник завтра получит двойку?

Хочешь программировать на выразительном и мощном языке: Python
Нужно по-быстрому веб-сайт: PHP
Желаешь в тусовку зовущих себя «рок-звездами» программирования: Ruby
Реально нужно научиться программировать: C
Ищешь просветления: Scheme
Уйти в хандру: SQL
Потерять одну хромосому: Microsoft Visual Basic
Для получения постоянной, заурядной, но хорошо оплачиваемой работы по созданию финансовых приложений в офисной загородке под лампами дневного света: Java
Тоже самое, но с аббревиатурами и списком сертификатов в своей подписи: C#
Получить волшебное ощущение детского изумления, которое сложно отличить от мании величия: Objective C

оригинал (en)

В качестве упражнения я хочу написать программу на С. Достаточно простую для того, чтобы дизассемблировать ее и объяснить весь код самой себе.

Звучит несложно, правильно?

У читателя предполагается наличие опыта компиляции программ и работы в Линуксе. Небольшое умение читать ассемблерный код тоже пригодится.

С год назад я столкнулся со странной «проблемой». Уже 7 лет как я занимаюсь программированием. Постепенно начал замечать «спад активности» — учить новое не хочется, рутиной заниматься не просто лень, а мега-лень, базы данных и обработка XML — в печенках уже сидит. И вдруг неожиданно понимаю, что программирование мне… надоело.



Что теперь делать? Как быть? Кто виноват? Ведь программирование — это то, что я всегда и больше всего любил. А самое важное — это то, чем я зарабатываю на жизнь. И больше не могу «это» делать.

Я попытаюсь рассмотреть проблему со всех сторон. Начнем с грустного.

Привет, хабрачеловеки!

Захотелось вот поделиться сокровенным знанием по этой теме. К тому же материалов по этому, достаточно важному принципу проектирования классов и их наследования, в Рунете как-то негусто. Имеются формулировки вида:

«Пусть q(x) является свойством верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.» © Wikipedia

Но они выносят мой мозг меня совершенно не радуют.

Если хочется услышать объяснение этой хрени умной фразы — прошу под кат.