Здравствуйте, Mystic, Вы писали:

VD>>И как таким подходом освоить что-то новое? Таким подходом можно освоить только то, что и так уже знаешь. А для этого изучаемые языки должны быть близнецами-братьями. С немерел это не так.

M>Новое осваивается на базе старого.

Ага. У кого-то старое — это курс математики средней школы. У кого-то — это знание С (без плюсов), Питона или Эрланга.

M>И для меня лучший способ освоения нового это решение практических задач. Так вот в случае с Nemerle эти статьи мне никак не помогают в решении этих задач. Точнее даже, задача не решается вообще.

Нельзя начинать решать сразу сложные задачи. Вывод таблицы перевода — это тоже практическая задача, но простая.
А что для тебя я уже сказал.

M>Лучше читателям объяснить, зачем вообще эти макросы нужны.

Объяснять — это не наш метод. Наш метод показывать.

M>Ну вот, я прочитал, знаю чтоони есть. Но вряд ли буду писать свои, потому как я просто не вижу, как их можно использовать. if/then/else уже написаны, больше мне не надо :)

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

VD>>Если ты уже знаком с C# и ты хочешь изучить только синаксис и его отличия от шарпа, то тебе просто нужно начать читать с другие статьи. Например — эту

Автор(ы): Сергей Туленцев, Владислав Чистяков
Дата: 23.05.2006
Производительность труда программиста в основном зависит от самого программиста. Однако даже самый опытный и знающий программист мало что может без подходящего инструмента. Эта статья открывает цикл статей об одном из таких инструментов, еще мало известном среди программистов, но очень многообещающем. Язык Nemerle, о котором пойдет речь в этих статьях, на первый взгляд очень похож на слегка улучшенный C#, но привносит многое из передовых исследовательских языков. Данная статья рассказывает об отличиях Nemerle от C# (как наиболее близкого языка)и является неформальным введением в язык.

.

M>C C# знаком поверхностно, если честно. Эту статью я смотрел, но тоже не очень помогла.

Ну, тогда на тебя не угодишь.

То что предлагаешь ты мне совсем не нравится.

M>Вот хочется раскрыть суть этой идеологии. if/else, while и даже большая часть операторов уже написана, вряд-ли мне придется их писать самому, только использовать. Для чего макросы нужны кроме того, чтобы реализовать основные конструкции других языков?

Я не могу научить тебя писать макросы которые нужны тебе. Я могу научить писать макросы вообще и дать общие сведения на базе которых ты, потом, сможешь сам понять что тебе может помочь макрос и написать его. По этому совершенно все равно какой макрос буду описыват я. Более того если я начну придумавать что-то сложное, то многие скажут, что лично им это не нужно. Кроме того я сильно усложню понимание. А понятность — это главное чего я хочу добиться.

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

Новичок не заметит никаких умолчаний. Для него их просто не будет. А рекурсия — это базовая вещь без которой нельзя. Да и нет в ней ничего сложного. По-моему, просто позор когда программист не понимает рекурсию.

VD>>Тебе, так как он мало отличается от того что ты видел в C#.
VD>>Кстати, хочется задать вопрос. Ты заметил отличия (в сравнении с C#) в использовании using?

M>Мой опыт в C# не настолько велик, но все-таки отметил.

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

Лучше ответь на один вопрос. Осталось ли что-то непонятное после прочтения данной стать?

M>Извращенный в том смысле, что надо раскручивать работу двух вложенных друг в друга match + рекрсивный, хотя задача этого не требует.

Куда раскручивать?
Я правильно понял, что извращением ты называешь использование рекурсии?

M>Собственно говоря, я хотел на Nemerle решить одну прикладную задачу. И почти обломался.

Чтобы решать прикладную задачу нужно прочитать не только первый раздел, но и (хотя бы) два следующих. А пока — это только введение.

Кстати, что значит "почти"?

M>Соответственно мне интересно увидеть, как при помощи (точнее без помощи всяких return и т. п.) можно решить более-менее практическую задачу. Ибо идеология это хорошо, в общих чертах мне понятно. Но на практике как только берется конкретная задача я наступаю на грабли.

Очень интересно было бы послушать и про грабли, и про конкретную задачу.

M>Я его уже нашел, как раз с его помощью немного "полегчало".

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

В прочем, было бы ОЧЕНЬ интересно узнать в чем были проблемы, как ты их решил и саму задачу.

Здравствуйте, VladD2, Вы писали:

VD>Ну, так он создан для быстрого нахождения фичь. Ты же взял совсем другой материал.
VD>В прочем, было бы ОЧЕНЬ интересно узнать в чем были проблемы, как ты их решил и саму задачу.

Задача примерно такая: генерация таблиц для того, чтобы выполнять оценивание руки из пяти карт в покере. Схема примерно такая: у карты есть номинал (тез, шестерка) и масть. Каждому номиналу карты сопоставляется простое число. Таким образом зная произведение этих простых числе в карточной комбинации, а также флеш это или нет, мы можем однозначно определить силу руки. Естественно, что вначале нам надо силу всех этих рук посчитать. В общем стоит задача построения примерно такого

  class Info
  {
    public int Product;
    public int FlushRank;
    public int NormalRank;
  }

  static public Dictionary<int, Info> Data;

объекта, который пригодится для построения талицы. Ключ это произведение простых чисел, соответствующих номиналу карт. Flush это сила комбинации при условии, что все карты одной масти. Normal это сила комбинации при условии, что не все карты одной масти.

Также я решил карту представлять списками, хоть это не совсем удобно в C#, но хотелось поучиться. Ну и в общем за несколько часов наступания на грабли родилось нечто такое, что считает только StraightFlush. После чего я устал и сделал большой перерыв.

using System.Console;
using System.Collections.Generic;

class Info
{
  public mutable Product: int;
  public mutable FlushValue: int;
  public mutable NormalValue: int;
}

def GlobalTable = Dictionary();

def Primary = array[2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41];

mutable rank = 1;

def AddFlushHand(hand)
{
  mutable Product = 1;
  foreach(card in hand)
    Product *= Primary[card];

  mutable info = Info();
  info.Product = Product;
  info.FlushValue = rank;
  info.NormalValue = -1;

  WriteLine(hand);
  WriteLine(info.Product);
  WriteLine();
  GlobalTable.Add(Product, info);
  rank = rank + 1;
}

mutable StraightFlush = [8, 9, 10, 11, 12];

AddFlushHand(StraightFlush);

foreach(card in [7, 6, 5, 4, 3, 2, 1, 0])
{
  StraightFlush = StraightFlush.Remove(card + 5);
  StraightFlush = StraightFlush + [card];
  AddFlushHand(StraightFlush);
}

AddFlushHand([3, 2, 1, 0, 12]);


WriteLine("Hello, World: " + GlobalTable.Count.ToString());

Для сравнения исходник на C#, который пишется без особого напряга за половину часа с отладкой:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace PokerTable
{
  class Info
  {
    public int Product;
    public int FlushRank;
    public int NormalRank;
  }

  class Program
  {
    static readonly int[] Primary = new int[] { 41, 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41 };

    static public int rank = 1;
    static public Dictionary<int, Info> Data = new Dictionary<int, Info>();
    
    static public void AddFlush(int Product)
    {
      Info info = new Info();
      info.Product = Product;
      info.FlushRank = rank;
      info.NormalRank = -1;
      Data.Add(Product, info);
      rank = rank + 1;
    }

    static public void AddNormal(int Product)
    {
      Info info;
      if (!Data.TryGetValue(Product, out info))
      {
        info = new Info();
        info.Product = Product;
        info.FlushRank = -1;
      }
      info.NormalRank = rank;
      rank = rank + 1;
    }

    static public void Straight(bool isFlush)
    {
      int Product = Primary[13] * Primary[12] * Primary[11] * Primary[10] * Primary[9];
      if (isFlush) AddFlush(Product); else AddNormal(Product);
      for (int i = 8; i >= 0; --i)
      {
        Product /= Primary[i + 5];
        Product *= Primary[i];
        if (isFlush) AddFlush(Product); else AddNormal(Product);
      }
    }

    static public void Quads()
    {
      for (int Base = 13; Base >= 1; --Base)
      for (int Kicker = 13; Kicker >= 1; --Kicker)
      {
        if (Base == Kicker) continue;
        int BasePrimary = Primary[Base];
        int KickerPrimary = Primary[Kicker];
        AddNormal(BasePrimary * BasePrimary * BasePrimary * BasePrimary * KickerPrimary);
      }
    }

    static public void FullHouse()
    {
      for (int Base = 13; Base >= 1; --Base)
      for (int Pair = 13; Pair >= 1; --Pair)
      {
        if (Base == Pair) continue;
        int BasePrimary = Primary[Base];
        int PairPrimary = Primary[Pair];
        AddNormal(BasePrimary * BasePrimary * BasePrimary * BasePrimary * PairPrimary);
      }
    }

    static public void Chanse(bool isFlush)
    {
      for (int card1 = 13; card1 >= 1; --card1)
      for (int card2 = card1 - 1; card2 >= 1; --card2)
      for (int card3 = card2 - 1; card3 >= 1; --card3)
      for (int card4 = card3 - 1; card4 >= 1; --card4)
      for (int card5 = card4 - 1; card5 >= 1; --card5)
      {
        if (card1 == 13 && card2 == 4) continue;

        bool isStraight = true  
          && card1 == card2 + 1 
          && card2 == card3 + 1 
          && card3 == card4 + 1 
          && card4 == card5 + 1
        ;
        
        if (!isStraight)
        {
          int Product = Primary[card1] * Primary[card2] * Primary[card3] * Primary[card4] * Primary[card5];
          if (isFlush) AddFlush(Product); else AddNormal(Product);
        }  
          
      }
    }
    
    static public void ThreeCards()
    {
      for (int Base=13; Base >= 1; --Base)
      for (int Kicker1 = 13; Kicker1 >= 1; --Kicker1)
      for (int Kicker2 = Kicker1 - 1; Kicker2 >= 1; --Kicker2)
      {
        if (Base == Kicker1) continue;
        if (Base == Kicker2) continue;
        AddNormal(Primary[Base] * Primary[Base] * Primary[Base] * Primary[Kicker1] * Primary[Kicker2]);
      }
    }

    static public void TwoPair()
    {
      for (int Base1 = 13; Base1 >= 1; --Base1)
      for (int Base2 = Base1 - 1; Base2 >= 1; --Base2)
      for (int Kicker = 13; Kicker >= 1; --Kicker)
      {
        if (Base1 == Kicker) continue;
        if (Base2 == Kicker) continue;
        AddNormal(Primary[Base1] * Primary[Base1] * Primary[Base2] * Primary[Base2] * Primary[Kicker]);
      }
    }

    static public void Pair()
    {
      for (int Base = 13; Base >= 1; --Base)
      for (int Kicker1 = 13; Kicker1 >= 1; --Kicker1)
      for (int Kicker2 = Kicker1 - 1; Kicker2 >= 1; --Kicker2)
      for (int Kicker3 = Kicker2 - 1; Kicker3 >= 1; --Kicker3)
      {
        if (Base == Kicker1) continue;
        if (Base == Kicker2) continue;
        if (Base == Kicker3) continue;
        AddNormal(Primary[Base] * Primary[Base] * Primary[Kicker1] * Primary[Kicker2] * Primary[Kicker3]);
      }
    }
  
    static void Main(string[] args)
    {
      Straight(true);
      Quads();
      FullHouse();
      Chanse(true);
      Straight(false);
      ThreeCards();
      TwoPair();
      Pair();
      Chanse(false);
      System.Console.WriteLine(rank);
    }
  }
}

Здравствуйте, Mystic, Вы писали:

M>объекта, который пригодится для построения талицы. Ключ это произведение простых чисел, соответствующих номиналу карт. Flush это сила комбинации при условии, что все карты одной масти. Normal это сила комбинации при условии, что не все карты одной масти.

M>Также я решил карту представлять списками, хоть это не совсем удобно в C#, но хотелось поучиться. Ну и в общем за несколько часов наступания на грабли родилось нечто такое, что считает только StraightFlush. После чего я устал и сделал большой перерыв.


M>Для сравнения исходник на C#, который пишется без особого напряга за половину часа с отладкой:
Ты меня, конечно, извини, но исходник — просто ужасен. Даже если не говорить про стиль оформления (вроде использования паскаль-кейзинга для локальных переменных), сам подход, на мой взгляд, в чистом виде инструкция "как не надо программировать ни на каком языке программирования".
Ну, вот например: ты начал с того, что выбрал представление для хранения руки. На-хре-на? Представление — дело десятое. Тебя интересует алгебра.
Поэтому программист на шарпе первым делом введёт некий абстрактный тип, описывающий набор карт, для которого определит необходимые операции.
При смене представления поменяется только реализация алгебраических операций. А у тебя по всему коду размазаны волшебные умножения и деления.
Далее, даже если использовать Тьюринговское представление твоих наборов (что, очевидно, крайне неэкономно по сравнению с bitstring), то все вот эти Primary[13] и так далее в нормальных программах запрещены — магические константы нужно заменить на именованные значения.

В-третьих, ты вместо задачи "оценить руку из пяти карт" решаешь какую-то постороннюю задачу "построить словарь". Она тебе зачем? Что этот словарь должен делать? Если расчёт оценки — дорогая штука, то имеет смысл что-то кэшировать. Программист на функциональном языке решает задачу "построить словарь" в последнюю очередь.
Сначала нужно сделать постановку задачи. То есть, к примеру, определиться с функциями.

Для покера нам достаточно функции Compare, которая отображает два hand на (-1, 0, 1). Вот задачу её построения и надо решать. Ок, пусть в процессе решения вывелось соображение о получении функции оценки: Compare = (Hand h1, Hand h2) => Compare(Rank(h1), Rank(h2)).
Введение какого-либо "словаря" внутрь функции Rank(Hand) — исключительно вопрос оптимизации. Сначала нужно получить алгоритмически корректное решение. Ты его получил? В твоём коде я этого не вижу. И только после того, как неэффективное решение будет получено, можно попробовать что-то улучшить. Например, включить кэширование. И вот тут уже будет ясно, к чему именно нужно применять кэширование — то ли ко всему результату, то ли к промежуточным расчётам.

В-четвёртых, из кода очевидно плохое знание стандартной библиотеки. У тебя в словаре дублируется значение ключа и одного из свойств значения. Вот это вот "Data.Add(Product, info)", где info.Product = Product — тавтология. Для таких случаев используют класс KeyedCollection.

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

Здравствуйте, VladD2, Вы писали:

VD>Возможно я и перемудрил в данном случае. Тут нужно на "кошках" экспериментировать, т.е. смотреть на реакцию тех кто действительно не знаком с программированием. Уверен, что те кто знали хотя бы какой-нибудь язык до чтения этого дела и так разобрались.

Ничего не перемудрил!
Если бы ты писал учебник программирования, то да, это бы только запутывало. Но ты же пишешь учебник языка для тех, кто в целом программировать умеет? Тогда и хорошо очень, что тривиальную и всем понятную задачу ты решаешь при помощи средств языка.

При этом никто не мешает тут же взять и попробовать определить какой-нибудь свой оператор

Кстати, кучу деклараций можно вынести в какую-то хитрую врезку "как оно устроено на самом деле". А в основном тексте сказать, что типа есть возможность задать приоритеты, и в стандартной библиотеке приоритеты такие-то. Но, как по мне, не так уж это и сложно прочитать эту декларацию. Только немного не понятно что такое "приоритет справа" и "приоритет слева". Это ассоциативностью управляет, насколько я понял?

Здравствуйте, Erop, Вы писали:

E> Только немного не понятно что такое "приоритет справа" и "приоритет слева". Это ассоциативностью управляет, насколько я понял?

Да. Но боюсь, что слова про ассоциативность еще больше запутают.

Здравствуйте, Sinclair, Вы писали:

S>Введение какого-либо "словаря" внутрь функции Rank(Hand) — исключительно вопрос оптимизации. Сначала нужно получить алгоритмически корректное решение. Ты его получил? В твоём коде я этого не вижу. И только после того, как неэффективное решение будет получено, можно попробовать что-то улучшить. Например, включить кэширование. И вот тут уже будет ясно, к чему именно нужно применять кэширование — то ли ко всему результату, то ли к промежуточным расчётам.

Я объяснял, что этот код решает только вспомогательную задачу. Общий код вычисление силы руки примерно такой

inline int only_one_bit_set(int mask)
{
  return mask & (mask - 1);
}

inline int is_flush(const card_t* cards)
{
  int mask = 0
    | get_suit(cards[0])
    | get_suit(cards[1])
    | get_suit(cards[2])
    | get_suit(cards[3])
    | get_suit(cards[4])
  ;

  return only_one_bit_set(mask);
}

inline int evaluate_5(const card_t* cards)
{
  int product = 1
    * primary[get_nominal(cards[0])]
    * primary[get_nominal(cards[1])]
    * primary[get_nominal(cards[2])]
    * primary[get_nominal(cards[3])]
    * primary[get_nominal(cards[4])]
  ;

  int index = is_flush(cards) : magic_flush[product % MAGIC_SIZE] ? magic_normal[product % MAGIC_SIZE];
  int delta = product % hand_ranks[index] + 1;
  return hand_ranks[index+delta];
}

Для корректной работы этого кода мне нужны массивы magic_flush, magic_normal и hand_ranks, которые и должен создать скрипт на C#/Nemerle. Собственно говоря, для построения этого скрипта и надо (1) построить тот словарь (2) обработать его.

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

Ок, как бы ты предложить более просто сформировать массивы magic_flush, magic_normal и ranks?

Здравствуйте, Sinclair, Вы писали:

S>Ну, вот например: ты начал с того, что выбрал представление для хранения руки. На-хре-на? Представление — дело десятое. Тебя интересует алгебра.

Зависит от задачи. Если код на 60% зависит от представления, то выбор представления очень важен. Есть и второй ньюанс: с этим представлением может быть связано очень много самых разных функций, то код получается неструктурированным. Ну например, в шахматах у нас есть класс "позиция", в нем тысяча методов, а все остальное всего ничего.

S>Для покера нам достаточно функции Compare, которая отображает два hand на (-1, 0, 1).

А достаточно ли? Самый простой пример вывести название комбинации, перейти в переборе рук к следующей. Не говоря уже о подсчете аутов и всяких других символических рассуждениях. Ты какую задачу решаешь, что так просто утверждаешь "достаточно"?

S>Введение какого-либо "словаря" внутрь функции Rank(Hand) — исключительно вопрос оптимизации.

Собственно задача и состоит в написании оптимальной версии. Проще говоря, я пишу библиотеку, где код должен работать оптимально. Где будет использована библиотека? Например, в покерном движке. Или в калькуляторе.

S>В-четвёртых, из кода очевидно плохое знание стандартной библиотеки. У тебя в словаре дублируется значение ключа и одного из свойств значения. Вот это вот "Data.Add(Product, info)", где info.Product = Product — тавтология. Для таких случаев используют класс KeyedCollection.

Я не знаток C#, тут согласен на все 100%

Здравствуйте, VladD2, Вы писали:

VD>Да. Но боюсь, что слова про ассоциативность еще больше запутают.

Статья супер, но я никак не доберусь до свободного времени, чтобы почитать с компьютером, а не просто с книжки.

Если кратко, то мне кажется, что надо сделать несколько модификаций.

1) сделать какие-то отступления для тех, кто хочет подробностей. Что-то типа сносок. Чтобы те, кому понятнее с ассоциативностями или там с оператором хитрым каким, посмотрели и обрадовались. Чем хорошо показывать потроха, так тем, что сразу можно экспериментировать

2) Мне кажется, что надо как-то собрать в кучку рекламу языка, и отделить её от собственно изложения. Можно по ходу дела писать ссылки назад. Типа "это одна из тех особенностей, которые обеспечивают ту мощность языка, о которой мы говорили выше"... Мне кажется, что люди, которым нужно узнать и люди, которым нужно захотеть узнать -- это разные люди. И первым надо дать возможность перейти сразу к делу, а вторых надо "обрабатывать" не переходя к "лишним" подробностям в самом начале. Может стоит привести пару примеров какого-нибудь крайне удачного кода, привести для сравнения код на шарпе, и пообещать, что к концу цикла читатель сможет переписать одно в другое сам. Или ещё какой рекламный трюк придумать (если реклама языка вообще входит в цели цикла)

3) IMHO, не надо по тексту апеллировать к K&R. Те, кто ценят эту книгу, всё равно узнают, а тем, кто не в курсе, не интересно. Можно отсылки к K&R вынести в эпиграфы какие-нибудь, во введение и т. д...
Лучше высказать вначале какие-то принципы, ну типа того, что ты хочешь рассказать о том, как работает язык, на примере его собственной стандартной библиотеки и нескольких относительно простых задач. Так что те, кто умеют программировать на чём-то другом, должны воспринимать этот цикл, как обзор того, что надо забыть, а что надо пересмотреть из знания, например, PASCAL, чтобы проникнуться N.

Я как доберусь так, чтобы с транслятором посидеть, отпишусь ещё.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>может, у тебя просто нет педагогического таланта?
Дык, это, если у тебя есть, то попробуй что-то предложить КОНСТРУКТИВНОЕ...

Здравствуйте, AndrewVK, Вы писали:

AVK>Ну, понимаешь — kiler app практически единственный шанс Немерле стать хоть сколько нибудь популярным. Так что твои слова фактически равносильны признанию, что сложившийся статус кво тебя устраивает.

Почему это практически единственный шанс? Почему, например, хороший учебник хуже?

Да и потом, ерунда это всё. Никаких kiler app не существует, на самом деле. Всё можно реализовать на всём...

Здравствуйте, Erop, Вы писали:


E>Почему это практически единственный шанс? Почему, например, хороший учебник хуже?

Хороший учебник массово читаемый в вузах конечно не хуже, только это по моему сложнее чем убойное приложение.

E>Да и потом, ерунда это всё. Никаких kiler app не существует, на самом деле. Всё можно реализовать на всём...

Ты их не видишь, но они есть

Здравствуйте, Erop, Вы писали:

E>Почему это практически единственный шанс?

Лично я других не вижу пока.

E> Почему, например, хороший учебник хуже?

Потому что, чтобы начать читать учебник, нужен хороший стимул.

E>Да и потом, ерунда это всё. Никаких kiler app не существует, на самом деле. Всё можно реализовать на всём...

Существуют, и еще как.

Здравствуйте, AndrewVK, Вы писали:

AVK>Существуют, и еще как.

Назови их, пожалуйста, для С++ и FORTRAN, например...

Здравствуйте, FR, Вы писали:

E>>Почему это практически единственный шанс? Почему, например, хороший учебник хуже?
FR>Хороший учебник массово читаемый в вузах конечно не хуже, только это по моему сложнее чем убойное приложение.
Ну я вот, например, C изучал потому, что у K&R учебник классный...

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

IMHO, опять же, продвижение и учебник -- это разные вещи...
Но хороший учебник поощряет продвижение, однако.

Здравствуйте, Erop, Вы писали:

E>Ну я вот, например, C изучал потому, что у K&R учебник классный...

Но распространился он из-за убойного UNIX.

E>IMHO, для того, чтобы язык освоило много программистов, надо чтобы его было или нужно или несложно осваивать. Можно влиять на разные множители вообще-то.

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

E>IMHO, опять же, продвижение и учебник -- это разные вещи...
E>Но хороший учебник поощряет продвижение, однако.

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

Здравствуйте, FR, Вы писали:

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

Ну так возможность легко въехать в два новых пласта могут быть как недостатком, так и достоинством

FR>Конечно, но без убойного приложения или богатого толкача даже с хорошим учебником есть риск занесения в "академические" языки. Такое произошло например с SML.

Ну есть намного более реальные риски. Например, он может надоесть Владу так же, как он надоел создателям...

Здравствуйте, Erop, Вы писали:

E>Назови их, пожалуйста, для С++ и FORTRAN, например...

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

Здравствуйте, Erop, Вы писали:

E>Ну так возможность легко въехать в два новых пласта могут быть как недостатком, так и достоинством

Возможности легко въехать нет, есть возможность легко начать изучать

FR>>Конечно, но без убойного приложения или богатого толкача даже с хорошим учебником есть риск занесения в "академические" языки. Такое произошло например с SML.

E>Ну есть намного более реальные риски. Например, он может надоесть Владу так же, как он надоел создателям...

Это да, но я верю в Влада

Здравствуйте, FR, Вы писали:

FR>Возможности легко въехать нет, есть возможность легко начать изучать
Ну это примерно одно и то же
В любом случае это может быть достоинством...

E>>Ну есть намного более реальные риски. Например, он может надоесть Владу так же, как он надоел создателям...
FR>Это да, но я верю в Влада

Ну я ещё и в язык верю, но это не исчерпывающий список.
Я к тому, что волков бояться -- в лес не ходить...

Здравствуйте, FR, Вы писали:

FR>Ну у C++ был очень крупный толкач, даже одно его использование одной из крупнейших компаний в отрасли было очень весомым фактором.

Ну, то есть, обошлось без "киллераппа"?
Понятно, что у всего, что стало популярным был какой-то путь к популярности. Но механически его воспроизводить таки глупо. Хороший язык постепенно приглянется кому-то настолько, что на нём появятся хорошие программы...