Не читал все комментарии, если уже было, прошу прощения.
В мужских фамилиях 2 раза встречается окончание ЦКИЙ. При наличии ЦКИЙ и СКИЙ — не проще ли один раз проверить КИЙ, или есть какие-то часто встречающиеся исключения? Какова вообще была методика отбора окончаний?
В женских окончаниях есть ЦКАЯ и АЯ. Если есть второе, первое уже не нужно, если я правильно понимаю.
А вообще — интересно, спасибо. Есть ли у вас база реальных имён тысяч на 50-100? По ней прогоняли, проверяли процент попаданий?
У меня второй монитор TN, я за такими редко сидел. Сейчас отношение к мягким цветовым схемам сильно изменилось. Например, хабр всегда казался мне читаемым, а на TN-матрице голубой цвет сильно сливается с белым, и читается с большим трудом.
Подумал я, подумал, и решил, что всё-таки контраст решает, не смотря на то, что дизайн получается жёстким и даже вызывающим.
Для программистов интересен поиск по API. Набираю я какой-нибудь Length, мне на выбор десяток ссылок на документацию. В идеале неплохо список предпочтений хранить в куках, чтобы приоритет был у частоиспользуемых API.
А то сейчас приходиться держать открытыми 4-5 вкладок.
Если сложность перенести из компилятора в VM, то сложнее станет одна VM и проще — множество компиляторов. В случае .NET этих компиляторов уже несколько штук (F#, Nemerle, возможно, IronPython и IronRuby).
> Компромисс, видимо, найден в том, что люди реализуют это в компиляторах,
> а не в VM.
Ровно наоборот. С течением времени, набор команд даже железных процессоров растёт — в том числе для того, чтобы упростить и ускорить всё, что выше микропроцессора. Что уж тут говорить о VM?
И осталось теперь обратить внимание на одну деталь: с течением времени самые часто-используемые техники реализуются на нижнем уровне, на уровне машинного кода, а в случае нашей дискуссии — на уровне байт-кода.
Не обязательно. Но реализаций VM без SL я ещё не видел. :)
> В любом случае, вместо QuickSort можно подставить кучу других алгоритмов посика,
> сортировки и т.п. Что, их всех в VM пихать?
Затем, что это конструкции разного уровня: алгоритм из ассемблерная инструкция. Можно ведь и в обратную сторону Ваш вопрос повернуть: зачем реализовывать на уровне процессора, например, арифметику с плавающей запятой, если компилятор прекрасно справляется?
Если я правильно понял, поддержка заключается в том, что используется сокращённый вариант вызова. Вместо CALL, по сути, используется обычный GOTO. Таким образом, если компилятор обнаруживает хвостовую рекурсию, он использует готовую инструкцию, а не занимается переводом в цикл самостоятельно.
> есть у меня определённые сомнения в том, что на десктопе так уж много задач, которые
> прямо «взлетят» от распараллеливания…
Я тоже не думаю, что взлетят. Скорее, появится поле для реализации более сложных функций. Помните время, когда проверка правильности текста выполнялась отдельно от его ввода? А потом в Office 2000 (если не в 97) текст стал проверяться «на лету». Машины дорасли. Но тогда всё это делалось на одном процессоре, а тут, пожалуйста — ещё несколько таких же процессоров под боком.
Из того, что у всех на виду, ожидаю серьёзных прорывов в компьютерных играх. Там производительность всегда актуальна.
Вот с точки зрения прикладного разработчика не всё однозначно. Но вот, скажем, такая частая операция, как построение отчётов, параллелится влёт.
> Где гарантия, что всё это станет действительно быстрее работать? А не начнётся
> пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и
> синхронизацией?
Вот тут не могу сказать. Насколько я представляю ситуацию сейчас, требуется определённый опыт параллельного программирования, чтобы избегать «опасных» способов распараллеливания. То есть, по сути, надо заставлять себя учиться новым способам думания. Но освоение функциональных языков в том числе предполагает изучение правильных способов думания.
> Только вот такие программы и на Си писать легко. Проблемы начинаются, когда
> возникает необходимость сделать «share something».
Я бы не сказал, что легко. Можно, но слишком многословно, и слишком нетрадиционно. Был у меня опыт написания библиотеки нечёткой логики на Си++, воспоминания весёлые. :) Закончилось тем, что когда я этот код пытался показывать другим программистам, они его не понимали, потому что воспринимали императивно. :)
Да, так вот, по поводу разделения ресурсов. Вы, конечно, правы. Но тут без конкретики уже очень сложно обсуждать. Вы приведёте мне проблему, которая не параллелится, я буду приводить проблему, которая хорошо параллелится, и так мы можем впасть в вечный цикл. :)
Ещё раз выскажу мысль о том, что HTML морально устарел ещё в начале века. И появление HTML 5, который как-то совсем не стыкуется с XHTML только увеличивает хаос.
Будущее за браузерами, которые одновременно являются виртуальными машинами.
В мужских фамилиях 2 раза встречается окончание ЦКИЙ. При наличии ЦКИЙ и СКИЙ — не проще ли один раз проверить КИЙ, или есть какие-то часто встречающиеся исключения? Какова вообще была методика отбора окончаний?
В женских окончаниях есть ЦКАЯ и АЯ. Если есть второе, первое уже не нужно, если я правильно понимаю.
А вообще — интересно, спасибо. Есть ли у вас база реальных имён тысяч на 50-100? По ней прогоняли, проверяли процент попаданий?
Получится — очень хорошо.
Подумал я, подумал, и решил, что всё-таки контраст решает, не смотря на то, что дизайн получается жёстким и даже вызывающим.
А за исследование спасибо, интересно.
Хотя фф жалко чисто по человечески.
А то сейчас приходиться держать открытыми 4-5 вкладок.
> Компромисс, видимо, найден в том, что люди реализуют это в компиляторах,
> а не в VM.
Ровно наоборот. С течением времени, набор команд даже железных процессоров растёт — в том числе для того, чтобы упростить и ускорить всё, что выше микропроцессора. Что уж тут говорить о VM?
Вот там вот, ниже, вопрос от shai_xylyd. Вы уверены, что KAWA будет вызывать виртуальную функцию через JUMP?
За счёт этого и компилятор упрощается.
Не обязательно. Но реализаций VM без SL я ещё не видел. :)
> В любом случае, вместо QuickSort можно подставить кучу других алгоритмов посика,
> сортировки и т.п. Что, их всех в VM пихать?
Затем, что это конструкции разного уровня: алгоритм из ассемблерная инструкция. Можно ведь и в обратную сторону Ваш вопрос повернуть: зачем реализовывать на уровне процессора, например, арифметику с плавающей запятой, если компилятор прекрасно справляется?
Лично сам Haskell таки изучаю, наравне с F#. Практика практикой, а упражнения для головы тоже не помешают. :)
Ну и работу по переводу обычной рекурсии в хвостовую приходиться делать самостоятельно. Вместо:
приходится писать что-то вроде:
У меня, например, NEC 20WGX2. Игры, фильмы, программирование — в полный рост. Сейчас думаю переходить на 22-24 дюйма.
> прямо «взлетят» от распараллеливания…
Я тоже не думаю, что взлетят. Скорее, появится поле для реализации более сложных функций. Помните время, когда проверка правильности текста выполнялась отдельно от его ввода? А потом в Office 2000 (если не в 97) текст стал проверяться «на лету». Машины дорасли. Но тогда всё это делалось на одном процессоре, а тут, пожалуйста — ещё несколько таких же процессоров под боком.
Из того, что у всех на виду, ожидаю серьёзных прорывов в компьютерных играх. Там производительность всегда актуальна.
Вот с точки зрения прикладного разработчика не всё однозначно. Но вот, скажем, такая частая операция, как построение отчётов, параллелится влёт.
> Где гарантия, что всё это станет действительно быстрее работать? А не начнётся
> пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и
> синхронизацией?
Вот тут не могу сказать. Насколько я представляю ситуацию сейчас, требуется определённый опыт параллельного программирования, чтобы избегать «опасных» способов распараллеливания. То есть, по сути, надо заставлять себя учиться новым способам думания. Но освоение функциональных языков в том числе предполагает изучение правильных способов думания.
> Только вот такие программы и на Си писать легко. Проблемы начинаются, когда
> возникает необходимость сделать «share something».
Я бы не сказал, что легко. Можно, но слишком многословно, и слишком нетрадиционно. Был у меня опыт написания библиотеки нечёткой логики на Си++, воспоминания весёлые. :) Закончилось тем, что когда я этот код пытался показывать другим программистам, они его не понимали, потому что воспринимали императивно. :)
Да, так вот, по поводу разделения ресурсов. Вы, конечно, правы. Но тут без конкретики уже очень сложно обсуждать. Вы приведёте мне проблему, которая не параллелится, я буду приводить проблему, которая хорошо параллелится, и так мы можем впасть в вечный цикл. :)
Будущее за браузерами, которые одновременно являются виртуальными машинами.
С функциональными значительно всё проще, вплоть до автоматического распараллеливания. Посмотрим, вдруг и окажется так, что хаскель быстрее си будет.