Уголок программиста

[PianoIst]

Иногда хочется обсудить вопросы не по конкретному случаю, или языку, а чуть более общие. Алгоритмические, или еще какие.
Вот, пусть будет здесь.
Передо мной встала задача как можно быстрее освоиться в питоне, и случай навел меня на замечательный проект, который мне лично, как не программисту и без классического образования оказался очень полезен и интересен:
http://adventofcode.com/
Вообще я его использую именно как занимательный способ быстро освоиться в языке (решаю третий день и уже делаю вещи, на которые в JSFX после месяца ковыряний с опаской смотрел). Но думаю и просто как разминка для ума и вводный толчек к олимпиадным заданиям будет полезен
С 1 декабря стартует новая сессия заданий

 

[Alex Longard]

Для начинающих или тех кто как я планирует переползать на Python3
http://pythonworld.ru

 

[PianoIst]

@Alex_028, спасибо, а то я все по официальному руководству бегаю)

 

[Alex Longard]

@PianoIst, будут вопросы - пишите, чем смогу - помогу.
Я с питоном дружу с 2007 года еще с Symbian и в институте сначала как обзор языка был впечатлился)))

 

[Намасте_намасте]

Интересно, а сейчас кто-нибудь на Форте пишет?

 

[vitalker]

Форте

фортран? Он используется разве что в банковском деле и то в самых старых банках

 

[Намасте_намасте]

@vitalker, именно Форт. FORTH

 

[vitalker]

@Намасте_намасте, видимо язык очень узкой специализации, потому что ни разу о нём не слышал.

 

[Намасте_намасте]

@vitalker, да нет там ничего узкого... Просто необычен немного... А выигрыша у него очень много. Вот что-то погуглил, и никто на нем VST не пишет.... А зря. Был эксперимент. Писалась одна программа одновременно на ассемблере и на Форте. После компиляции, размер исполняемого модуля после Форта был меньше чем после Ассемблера.

 

[bloodykot]

@vitalker, да нет там ничего узкого... Просто необычен немного... А выигрыша у него очень много. Вот что-то погуглил, и никто на нем VST не пишет.... А зря. Был эксперимент. Писалась одна программа одновременно на ассемблере и на Форте. После компиляции, размер исполняемого модуля после Форта был меньше чем после Ассемблера.

Размер совсем не показатель. Реализовать объектно-ориентированные штучки в ассемблере- дело не тривиальное при большом объеме кода. Объем кода на ассемблере если специально не морочится этим всегда будет выше, а гибкость существенно ниже. Ничего особого в этом Forth ИМХО нет. Мертворожденный язык, канувший в прошлое.

 

[Намасте_намасте]

@bloodykot, есть и ООП надстройки, так что все вроде в норме. Но, соглашусь, язык для фриков. Хотя было бы любопытно...

 

[Morpheus]

Тоже начитался про популярность пайтона. Чуть вник - этож интерпретируемый язык. Не для десктопа он. Для Web - может да. Всё хотят порог вхождения понизить, чтоб говнокодеров побольше было. С++ наше все, ну может С#, хотя там тоже прокладка в виде .Net. Про Delphi промолчу, хотя не понимаю, почему его так хают. Про то, что программа на Forth после компиляции меньше чем на ассемблере - спасибо, поржал.

 

[Намасте_намасте]

@Morpheus, я рад что доставил вам удовольствие ))) Но сначала разберитесь с вопросом. )))

 

[Morpheus]

@Намасте_намасте, ну смотрите - Forth - язык программирования более высокого уровня, чем ассемблер. А значит он компилируется в ассемблер. Так, что размер скомпилированной программы по определению не может быть меньше программы на ассемблере. Просто, наверно, тот кто писал на ассемблере был менне хорошим программистом .

 

[Намасте_намасте]

@Morpheus, а вы часто пишите на ассемблере? С лету напишите готовый продукт?

 

[Morpheus]

Вообще не пишу - и думаю никто не пишет. Зачем, если есть языки высокого уровня. Как-то давно в детстве на ассемблере Z80 пробовал игрушку писать . Я могу поверить, что синтаксис языка настолько лаконичный, что в текстовом виде программа будет меньше, чем ассемблерная. Но это значит, что она интерпретируемая, и все равно после интерпретации в ОЗУ она будет занимать, по крайней мере, не меньше места, чем ассемблерная.

 

[Намасте_намасте]

@Morpheus, это интерпретатор-компилятор. Суть в чем. Все базовые слова написаны на ассемблере. Это и ежу понятно. При чем есть слова которые состоят из одной ассемблерной команды. Сами понимаете, что оптимизация этих мелких блоков которые по 3-15 команд просто сумасшедшая. Так вот. Создавая программу на ассемблере, очень трудно добиться максимальной оптимизации. И чем программа больше, тем сложнее ее оптимизировать на ассемблере. Тем не менее, Форт - обычная обертка для ассемблера. Его прелесть в том, что сама программа, это одно слово (команда в других языках). Т. .е оптимизация просто на офигительном уровне. Вот отсюда и разница в размерах исполняемых модулей. Никакого волшебства. Кстати сам писал на ассемблере, правда под отечественный КР580.

 

[Alex_V]

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

 

[Morpheus]

@Намасте_намасте, Мы, наверно, разное понимаем под ассемблером. Для меня ассемблер - это чуть очеловеченные машинные коды типа 00000011 11001010 - на ассемблере
mov ax, 0xCA (как пример). И все языки программирования, в принципе, можно назвать оберткой над ассемблером. И всегда конечный результат компиляции (или интерпретации) будет ассемблерный (машинный, двоичный) код. Поэтому,ни один код на языке более высокого уровня не может быть лучше, эффективнее или меньше, чем код на ассемблере. В случае, если это просто обертка над ассемблером, то он будет таким же (после компиляции).

 

[Намасте_намасте]

@Morpheus, про этот ассемблер я и писал. Тем не менее факты есть. Попробую найти ссылки.
[DOUBLEPOST=1511561464][/DOUBLEPOST]@Alex_V, мы про оптимизацию. А это всегда важно.

 

[Morpheus]

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

Ага, шикарно, теперь мы имеем простецкую программу с подтянутыми фреймворками, весящую, как ОС. Действительно, а зачем париться, придумывать какой-нибудь, скажем парсер, если можно присоединить фреймворк, который содержит этот парсер мегабайт так на 60, а вы покупайте винты побольше, ОЗУ побольше, процессоры побыстрее. Hello World на Xamarin занимает 16МБайт - просто офигеть.

 

[Alex_V]

мы про оптимизацию. А это всегда важно.

Если говорить про оптимизацию, то сейчас это тоже достаточно тонкий вопрос. Потому, что достаточно немалая часть оптимизации теперь тоже делается вовсе не при написании кода, а компилятором и потом еще до кучи процессором во время выполнения - вот это все распараллеливание выполнения, предсказание ветвлений и всё такое. В результате не факт, что написанный вручную на ассемблере код может оказаться выполняющимся более эффективно, чем сгенерированный компилятором языка более высокого уровня.
При этом я не хочу сказать, что компилятор может сделать из плохого кода хороший и можно писать как попало.
[DOUBLEPOST=1511562596][/DOUBLEPOST]

Hello World на Xamarin занимает 16МБайт - просто офигеть.

Во-во-во. Сравнивать эффективность фреймворков по размеру Hello World - еще один детский сад. Фреймворки (любые) не для этого создавались. Это даже не из пушки по воробьям. Это ядерной бомбой.

 

[user811]

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

 

[Намасте_намасте]

@Morpheus, "Точно так же скомпилированные Форт-программы имеют очень маленький размер - обычно меньше эквивалентных программ на ассемблере. Причиной опять же является шитый код. Каждая ссылка на предварительно определенное слово, независимо от его мощности, использует всего два байта."
Leo Brodie
Thinking FORTH
A Language and Philosophy for Solving Problems
Englewood Cliffs, N.J., Prentice-Hall, Inc., 1984

 

[user811]

Точно так же скомпилированные Форт-программы имеют очень маленький размер - обычно меньше эквивалентных программ на ассемблере.

Платой за маленький размер шитого кода обычно является более медленная работа.

 

[Morpheus]

Платой за маленький размер шитого кода обычно является более медленная работа.

Ага, то же сейчас завикипедил

 

[Намасте_намасте]

Платой за маленький размер шитого кода обычно является более медленная работа.

Статистика - 20-30% от скорости программы на ассемблере.

 

[Morpheus]

Во-во-во. Сравнивать эффективность фреймворков по размеру Hello World - еще один детский сад. Фреймворки (любые) не для этого создавались. Это даже не из пушки по воробьям. Это ядерной бомбой.

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

 

[Намасте_намасте]

Так в том-то и проблема, что современные говнопрограммеры не решают проблемы

Быдлокод порожден излишними ресурсами ))))

 

[Morpheus]

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

Естественно, никто в здравом уме не захочет переплюнуть ни диспетчера задач, ни менеджер памяти ОС или IDE. На секунду представил на ассемблере многопоточное приложение. Бррррр...