Не выйдет. Microsoft — публичная компания, поэтому ежегодно она публикует финансовые отчёты.
Прибыль составляет 30%. Это означает, что если Microsoft скинет цену на свои продукты на 30%, акционеры останутся вообще без прибыли. А если на 50%, то компания уйдёт в минуса.
Странно, за что Вас минусуют? Я проверял советы для начинающих бизнесменов на собственном опыте и совершенно согласен: всё дело в удаче. Т.е., в принципе, можно создать неплохой прибыльный бизнес, для этого, наверное, и удача не нужна.
1. Мы уже на "ты"?
2. Да, это я поторопился написать.
Естественно, наоборот.
3. Нет. Один раз описать логику работы,
транслировать её в низкоуровневый код,
а он уже будет работать.
4. Языки, на которых писал? Язык
Ассемблера ZX Spectrum и x86/386,
Си, Паскаль, Фортран, Фоал, Бейсик,
Си++, Object Pascal, Perl, PHP,
Java, C#.
5. Реплики не понял.
Кстати, лично я с этим согласен. И на мой взгляд,
в Хаскелле первая запись очень изящно выражается,
правда, и использованием нелюбимой Вами хвостовой
оптимизации.
> мне как-то нет дела до всяких "независимых бенчмарков". своим глазам я доверяю больше.
Но я Вашим глазам не доверяю. Те ссылки,
которые я привёл выше, они от независимых
исследователей, имеющих вес. Про Вас мне
ничего не известно, так что я могу предполагать
подтасовку фактов, либо просто несостоятельность
в деле сравнения архиваторов. Извините.
> не надо путать декларативные языки с функциональными.
А я и не путаю. Декларативные языки — это
подмножество функциональных, предназначенные
для описания.
> на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
Я себе сам процесс представляю по другому.
На входе мы имеем описание окна, которое
разворачивается в низкоуровневые (императивные)
инструкции. Вот это вот разворачивание
гораздо проще делать на ФПЯ.
> не надо судить об императивном
> программировании лишь по одному
> убогому, но крайне популярному
> представителю.
[ржОт]
Я на императивных языках пишу с 1988-го
года. А ФП изучаю, дай бог, года три, и то
не очень плотно. Уж если и могу о чём
судить, так об императивном
программировании. :)
> там, где программисты просто используют
> цикл - там уже нет ФП. это самый обычный
> императивный язык с функциями, где
> программа из проского списка комманд
> переписана через последовательность
> вызова этих самых функций.
Я никогда не рассматривал этот вопрос
с позиций или-или. И Руби, и Хаскель позволяют
писать и императивно, и функционально. Всегда
есть возможность выбрать подходящую парадигму.
А вот Си++ функционально писать позволяет
с большим трудом (я реализовывал нечёткую
логику на Си++, там слишком многословно
получается — т.е. можно, но непросто).
> затем, что каждое приложение стремится заюзать всю свободную память.
Это не аргумент, это лозунг. Мы с Вами, как программисты, можем оперировать
тезисами и аргументами? Это же не митинг.
> чем больше среднему пользователю доступно памяти, тем более развязно пишут свои
> программы разработчики.
Моё личное мнение по этому вопросу с Вашим не совпадает. Я понмю времена, когда промышленные
программы писали на языке ассемблера. Потом их стали писать на C и на Паскале. Потом на C++.
Теперь на Java и C#.
И каждый раз находился кто-то, кто говорил: "Куда катится мир?" Каждый раз.
> затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
Да, есть микроконтроллеры, и там пишут на ассемблере и Си. Да, есть устаревшая техника, которую
жалко выбрасывать. Эти факты не отменяют существующей тенденции в мире ПК: памяти становится
больше, процессоры становятся многоядерными.
> затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их
> прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
Да, одни компьютер не в состоянии заменить 10 компьютеров того же класса. С моей точки зрения,
здесь нет ничего удивительного.
> затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
А вот здесь я просто не понял. Поправьте меня, если я ошибаюсь: вы на флешку запишите музыку,
вместо того, чтобы хранить там переносимую ОС? А ОС запишите на дискету?
Freearc при сопоставимой степени сжатия работает быстрее. При сопоставимой скорости
сжимает лучше. С чем здесь спорить?
Даже если ФЯП не применимы во всех случаях, они прекрасно подходят для решения
некоторых классов задач. Архиваторы — неплохой пример. Пользовательские интерфейсы
тоже значительно удобнее описывать декларативно, чем императивно.
> вообще, довольно глупо тянуть чисто математическую абстракцию на чисто
> императивную архитектуру компьютера. всё-равно интерпретатору приходится
> конвертировать функциональную программу к императивной форме.
Машина должна работать, человек — думать. Функциональные языки повышают
производтельность программиста. Поэтому мне лично непонятно, почему "глупо" возложить
на железку задачу перевести высокоуровневые конструкции в низкоуровневые?
На C++ мне приходится делать это самостоятельно, и каждый раз ручками.
> особенно убивает реализация естественных для человека циклов через рекурсию и
> дальнейшие шаманства с "хвостовой оптимизацией"...
Зачем же так? Практическое программирование отличается от академического. Там, где в
ФП нужен цикл, программисты просто используют цикл.
Неправда. freearc быстре 7-zip и rar, хотя писан на Хаскелле. Вот авторам этих архиваторов
придётся изрядно потрудиться, чтобы на многоядерные процессоры пересесть. А в Хаскелле с этим
никаких проблем.
И? Гигабайт памяти стоит сейчас меньше тысячи рублей. А через год будут стоить 500.
Вы на чём собираетесь экономить?
Зачем ОС, которая умещается на дискету, если удельная стоимость USB-диска на порядки ниже? То, чем
занимаются минуетные ребята, это 70-е годы программирования (уместить программу в 64К). Мы с Вами можем
решать другие задачи, те, про которые в 70-е даже не мечтали. Зачем себя ограничивать?
Вопрос, на мой взгляд, слишком общий. С моей точки зрения, язык Си очень выразительный.
И вопрос эффективности очень многозначный. Через 2 года у народа массово будут стоять 2-4-8 ядерные машины.
Для Си++ программистов мультитредные приложения — это отдельный геморрой. А для функциональщиков — что-то такое,
о чём даже не стоит беспокоиться.
Наоборот, хорошо. Богу божье, цезарю всё остальное.
Ядерщиков сейчас доли процента. Из моих личных знакомых, вот только авторы sphinx (поисковой машины) пишут на C++, да я (2-й
раз за последние 3 года). Ну, ещё те бедолаги, которые поддерживают проект, начатый в 98-м. :)
Для прикладного программирования нужны прикладные же средства.
1. Каррированность (не знаю, как правильнее по-русски сказать). Есть не во всех ФП-языках, насколько я помню, но теоретические основы и практическая реализация заложены именно функциональщиками. Означает, что если у функции
есть N параметров, и мы установим значения для M из них, то у нас появляется новая функция с (N - M) параметрами.
Проще всего приводить пример с распространённой функцией map, которая на входе получает функцию с одним параметром и список, и применяет функцию ко всем параметрами. Получается что-то вроде такого:
map (+5) [2, 3, 4, 1, 17] прибавляем 5 ко всем элементам списка
map (2^) [2, 3, 4, 1, 17] получаем степень 2-ки для всех элементов списка
Это был Хаскелл. А вот Руби (удаление всех файлов с расширением .tmp из каталога C:\temp):
2. При вызове лябда-функции в её теле доступны локальные переменные вызывающей функции. Тоже, вроде бы, не во всех
ФП-языках есть эти самые замыкания (closures), но в Руби и C# есть.
Тут писал несколько по памяти, поэтому возможны синтаксические неточности, но смысл передан верно. Основное отличие
от императивных языков в том, что всё здесь делается in place, в одну строку. Теоретически, всё это можно и на C/C++
делать, но — всё вручную. Хочешь замыкание — пиши класс с состоянием. А функции каррируй вручную.
Я вот тоже удивляюсь. В конце концов, некий freearc рвёт по скорости и степени сжатия и 7-zip и rar, а ведь написан на Хаскелле. Справедливости ради скажу, что там и C/C++ код есть, но тем не менее.
Автоформатирование надо отключить, тогда <br /> после каждой строки вставляться не будет. Впрочем, это тоже геморрой. На хабре давно пора предусмотреть тег habrapre, чтобы внутри pre переносы строк не вставлялись. :)
А забытый пароль как восстанавливать, если нет подтверждённого адреса электронной почты?
Идея очень понравилась.
Прибыль составляет 30%. Это означает, что если Microsoft скинет цену на свои продукты на 30%, акционеры останутся вообще без прибыли. А если на 50%, то компания уйдёт в минуса.
в праве иметь суждения об
императивных языках? :)
Хорошо, тогда дискуссию
следует прекратить. Вам
следует общаться с кем-нибудь
поумнее.
А вот стать миллиардером — уже нет. :)
2. Да, это я поторопился написать.
Естественно, наоборот.
3. Нет. Один раз описать логику работы,
транслировать её в низкоуровневый код,
а он уже будет работать.
4. Языки, на которых писал? Язык
Ассемблера ZX Spectrum и x86/386,
Си, Паскаль, Фортран, Фоал, Бейсик,
Си++, Object Pascal, Perl, PHP,
Java, C#.
5. Реплики не понял.
в Хаскелле первая запись очень изящно выражается,
правда, и использованием нелюбимой Вами хвостовой
оптимизации.
Но я Вашим глазам не доверяю. Те ссылки,
которые я привёл выше, они от независимых
исследователей, имеющих вес. Про Вас мне
ничего не известно, так что я могу предполагать
подтасовку фактов, либо просто несостоятельность
в деле сравнения архиваторов. Извините.
> не надо путать декларативные языки с функциональными.
А я и не путаю. Декларативные языки — это
подмножество функциональных, предназначенные
для описания.
> на чисто функциональном языке, например, невозможо сделать простой чекбокс на форме. чтобы изменить его состояние, нужно отправить всё окно на съедение автоматическому сборщику мусора и с нуля сгенерировать новое, но с другим состоянием чекбокса.
Я себе сам процесс представляю по другому.
На входе мы имеем описание окна, которое
разворачивается в низкоуровневые (императивные)
инструкции. Вот это вот разворачивание
гораздо проще делать на ФПЯ.
> не надо судить об императивном
> программировании лишь по одному
> убогому, но крайне популярному
> представителю.
[ржОт]
Я на императивных языках пишу с 1988-го
года. А ФП изучаю, дай бог, года три, и то
не очень плотно. Уж если и могу о чём
судить, так об императивном
программировании. :)
> там, где программисты просто используют
> цикл - там уже нет ФП. это самый обычный
> императивный язык с функциями, где
> программа из проского списка комманд
> переписана через последовательность
> вызова этих самых функций.
Я никогда не рассматривал этот вопрос
с позиций или-или. И Руби, и Хаскель позволяют
писать и императивно, и функционально. Всегда
есть возможность выбрать подходящую парадигму.
А вот Си++ функционально писать позволяет
с большим трудом (я реализовывал нечёткую
логику на Си++, там слишком многословно
получается — т.е. можно, но непросто).
Это не аргумент, это лозунг. Мы с Вами, как программисты, можем оперировать
тезисами и аргументами? Это же не митинг.
> чем больше среднему пользователю доступно памяти, тем более развязно пишут свои
> программы разработчики.
Моё личное мнение по этому вопросу с Вашим не совпадает. Я понмю времена, когда промышленные
программы писали на языке ассемблера. Потом их стали писать на C и на Паскале. Потом на C++.
Теперь на Java и C#.
И каждый раз находился кто-то, кто говорил: "Куда катится мир?" Каждый раз.
> затем, что в мой ноут больше гига не всунуть, а есть платформы в которых памяти и того меньше.
Да, есть микроконтроллеры, и там пишут на ассемблере и Си. Да, есть устаревшая техника, которую
жалко выбрасывать. Эти факты не отменяют существующей тенденции в мире ПК: памяти становится
больше, процессоры становятся многоядерными.
> затем, что мне нужно тестировать свои программы в десяти различных средах и из-за их
> прожорливости приходится останавливать одну виртуальную машину, чтобы запустить другую.
Да, одни компьютер не в состоянии заменить 10 компьютеров того же класса. С моей точки зрения,
здесь нет ничего удивительного.
> затем, что на гигабайт usb-диска я лучше залью сотню-другую песен и буду наслаждаться разнообразием репертуара в дороге.
А вот здесь я просто не понял. Поправьте меня, если я ошибаюсь: вы на флешку запишите музыку,
вместо того, чтобы хранить там переносимую ОС? А ОС запишите на дискету?
http://www.squeezechart.com/main.html
http://www.metacompressor.com/
http://maxcompress.narod.ru/
http://www.maximumcompression.com/data/s…
Freearc при сопоставимой степени сжатия работает быстрее. При сопоставимой скорости
сжимает лучше. С чем здесь спорить?
Даже если ФЯП не применимы во всех случаях, они прекрасно подходят для решения
некоторых классов задач. Архиваторы — неплохой пример. Пользовательские интерфейсы
тоже значительно удобнее описывать декларативно, чем императивно.
> вообще, довольно глупо тянуть чисто математическую абстракцию на чисто
> императивную архитектуру компьютера. всё-равно интерпретатору приходится
> конвертировать функциональную программу к императивной форме.
Машина должна работать, человек — думать. Функциональные языки повышают
производтельность программиста. Поэтому мне лично непонятно, почему "глупо" возложить
на железку задачу перевести высокоуровневые конструкции в низкоуровневые?
На C++ мне приходится делать это самостоятельно, и каждый раз ручками.
> особенно убивает реализация естественных для человека циклов через рекурсию и
> дальнейшие шаманства с "хвостовой оптимизацией"...
Зачем же так? Практическое программирование отличается от академического. Там, где в
ФП нужен цикл, программисты просто используют цикл.
придётся изрядно потрудиться, чтобы на многоядерные процессоры пересесть. А в Хаскелле с этим
никаких проблем.
Вы на чём собираетесь экономить?
Зачем ОС, которая умещается на дискету, если удельная стоимость USB-диска на порядки ниже? То, чем
занимаются минуетные ребята, это 70-е годы программирования (уместить программу в 64К). Мы с Вами можем
решать другие задачи, те, про которые в 70-е даже не мечтали. Зачем себя ограничивать?
И вопрос эффективности очень многозначный. Через 2 года у народа массово будут стоять 2-4-8 ядерные машины.
Для Си++ программистов мультитредные приложения — это отдельный геморрой. А для функциональщиков — что-то такое,
о чём даже не стоит беспокоиться.
Ядерщиков сейчас доли процента. Из моих личных знакомых, вот только авторы sphinx (поисковой машины) пишут на C++, да я (2-й
раз за последние 3 года). Ну, ещё те бедолаги, которые поддерживают проект, начатый в 98-м. :)
Для прикладного программирования нужны прикладные же средства.
1. Каррированность (не знаю, как правильнее по-русски сказать). Есть не во всех ФП-языках, насколько я помню, но теоретические основы и практическая реализация заложены именно функциональщиками. Означает, что если у функции
есть N параметров, и мы установим значения для M из них, то у нас появляется новая функция с (N - M) параметрами.
Проще всего приводить пример с распространённой функцией map, которая на входе получает функцию с одним параметром и список, и применяет функцию ко всем параметрами. Получается что-то вроде такого:
map (+5) [2, 3, 4, 1, 17] прибавляем 5 ко всем элементам списка
map (2^) [2, 3, 4, 1, 17] получаем степень 2-ки для всех элементов списка
Это был Хаскелл. А вот Руби (удаление всех файлов с расширением .tmp из каталога C:\temp):
Dir.foreach("C:\\temp\\*.tmp", { |filename| File.delete(filename) }
2. При вызове лябда-функции в её теле доступны локальные переменные вызывающей функции. Тоже, вроде бы, не во всех
ФП-языках есть эти самые замыкания (closures), но в Руби и C# есть.
Например:
Time monthAgo = Time.now - 60 * 60 * 24 * 30;
Dir.foreach("C:\\temp\\*.tmp", { |filename| if(File.stat(filename).atime < monthAgo) File.delete(filename) }
Тут писал несколько по памяти, поэтому возможны синтаксические неточности, но смысл передан верно. Основное отличие
от императивных языков в том, что всё здесь делается in place, в одну строку. Теоретически, всё это можно и на C/C++
делать, но — всё вручную. Хочешь замыкание — пиши класс с состоянием. А функции каррируй вручную.