Здравствуйте, samius, Вы писали:
V>>>>А самое смешное с этим дотнетом то, что нормальные языки он не поддерживает. Т.е. идея о том, что всякие разные языки могут использовать общую библиотеку работает не со всеми языками.
S>>>А разве где-то заявлялось что дотнет смогут использовать ВСЕ языки? Уверен, речь шла только о языках на дотнет платформе.
V>>Речь шла о том, что вот мол платформа (сиречь библиотеки), а вот виртуальная машина, теперь можно быстро наклепать поверх реализацию любого языка, не сильно заморачиваясь с компиляцией, да еще и получить простой интерфейс к куче библиотек от МС (типично МС-овский подход, кстати: любой язык, но на нашей платформе). S>Про любой язык лично от Microsoft ничего не слышал, но да, такая замануха была.
Я про эту замануху и говорю.
V>>Т.е. рекламируемый смысл дотнета "фигачьте компилер вашего любимого языка под нашу платформу и получайте язык+библиотеки=профит", стоит переделать как "привяжитесь к МС навсегда", а языки -- это так замануха. S>Да. Ну а как иначе? Я когда вижу рекламу чего-то, я же не бегу его покупать. И тут так же. Прежде чем переводить свой любимый язык на дотнет, надо сначала понять, а можно ли это сделать, а надо ли это делать? Если нужно, можно и цели окупают средства, то только тогда вперед, а не только потому что на рекламу поддался.
Дело в том, что на рекламу "у нас тут не жаба, у нас тут куча языков, да еще и библиотек тонна" поддалось большое кол-во народа. Притом, что дотнет мягко говоря не самая лучшая платформа для разработки приложений. Т.к. среди кучи языков удобных мало, а библиотеки низкоуровневые.
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Да. Ну а как иначе? Я когда вижу рекламу чего-то, я же не бегу его покупать. И тут так же. Прежде чем переводить свой любимый язык на дотнет, надо сначала понять, а можно ли это сделать, а надо ли это делать? Если нужно, можно и цели окупают средства, то только тогда вперед, а не только потому что на рекламу поддался.
V>Дело в том, что на рекламу "у нас тут не жаба, у нас тут куча языков, да еще и библиотек тонна" поддалось большое кол-во народа. Притом, что дотнет мягко говоря не самая лучшая платформа для разработки приложений. Т.к. среди кучи языков удобных мало, а библиотеки низкоуровневые.
Основной народ из тех что повелся, повелся не на кучу языков, а конкретно
* на C#
* на платформонезависимость CLR, полагая что совместимость будет гораздо большей
* на тонну библиотек, которых действительно тонна из коробки, и еще куча сверху
Тех, кто кинулся писать компиляторы языков под дотнет, не так много. А кто приуспел в этом — по пальцам пересчитать.
Но и это уже хорошо, потому как когда актвино пиарился .NET 1.0, лично я серьезно не расчитывал, что будет что-то кроме C#, VB.NET и ME for C++
Да и выбора на тот момент было не густо. И сейчас выбору не густо, особенно если принимать во внимание не только высокоуровневость языков, но и уровень досягаемых разработчиков, особенно на перефирии.
Здравствуйте, vshabanov, Вы писали:
L>>1) чем слабее?
V>Меньше фич. Объекты там дотнетовские, а не окемловские (лучшее ОО из того, что я видел, только почти не используется за ненадобностью). Полиморфных вариантов вроде тоже нет. Система модулей вроде тоже слабее.
В копилку: ограниченные алгебраические типы данных — представленны только "суммами" ("discriminated unions").
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, Mr.Cat, Вы писали:
MC>>Здравствуйте, Mr.Cat, Вы писали: V>>>>когда SPJ в Москве был MC>>>Это записано на видео? MC>>Сорри, это вопрос был.
V>Видео на MskHUG вроде писали, но похоже нигде не выложили. А на видео с евангелистом от майкрософт (проподом по F#, насколько я понял) такие вопросы ему вряд-ли задавали.
Здравствуйте, Курилка, Вы писали:
V>>Видео на MskHUG вроде писали, но похоже нигде не выложили. А на видео с евангелистом от майкрософт (проподом по F#, насколько я понял) такие вопросы ему вряд-ли задавали.
К>Есть вот такое интервью
Здравствуйте, Gollum, Вы писали:
G>Интересно было бы услышать о:
V>>Притом, что дотнет мягко говоря не самая лучшая платформа для разработки приложений.
G>А какая самая лучшая?
А лучше без платформы. Собираешь наиболее подходящие для тебя библиотеки, а не зажимаешься в выданном свыше.
V>> Т.к. среди кучи языков удобных мало,
G>Удобных для кого/чего? Какие языки удобны?
Для программистов/разработки приложений. Удобны хаскелл/окемл/эрланг, некоторым лисп/питон/руби. Возможно, если есть все готовое, и надо плотно взаимодействовать с МС-продуктами, то можно и что-то из дотнета (но как только дойдем до хоть какой-то логики, не реализованной библиотеками/компонентами -- а это бывает почти всегда, сразу станет неудобно).
V>> а библиотеки низкоуровневые.
G>WPF, WF, WCF, Dynamic Data, etc — низкоуровневые? А какие тогда высокоуровневые?
Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. wpf -- см tcl/tk, wf -- фигачишь dsl и не паришься, wcf -- см эрланг, Dynamic Data -- судя по примерам тот еще монстр, и без IDE с ним наверное не справиться (а без IDE он похож на php, хотя не разбирался), посмотри на ur и всякие web фреймворки для того же эрланга
Здравствуйте, vshabanov, Вы писали:
V>Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. V>wpf -- см tcl/tk, V>wf -- фигачишь dsl и не паришься, V>wcf -- см эрланг,
Твои примеры — едва ли аналогичны. Tcl/tk — это вообще смешно сравнивать. Как говаривал тут один участник — фтопку (c)
Здравствуйте, vshabanov, Вы писали:
L>>ЗЫ. Выходит, все-таки можно под .нет реализовать необходимые языки?
V>Еще очень интересно, как под дотнетом можно реализовать GADT/type families/type classes? Чтобы их еще с дотнета можно было использовать ))
Да никак, и дотнет тут не причем. В любой системе, ориентированной на бинарное распространение библиотек, языки типа Хаскель не реализуемы. "Предкомпилированные" билиотеки Хаскеля — это просто еще одна разновидность исходного кода, вот в чем "системная" причина несовместимости подходов. Ну дык и сам Хаскель ввиду этого не особо интероперабелен, а лишь в очеь ограниченном диапазоне возможностей, куда как более ограниченном, чем ограничения среды .Net.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, vshabanov, Вы писали:
V>>Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. V>>wpf -- см tcl/tk, V>>wf -- фигачишь dsl и не паришься, V>>wcf -- см эрланг, F> Твои примеры — едва ли аналогичны. Tcl/tk — это вообще смешно сравнивать. Как говаривал тут один участник — фтопку (c)
Здравствуйте, vdimas, Вы писали:
L>>>ЗЫ. Выходит, все-таки можно под .нет реализовать необходимые языки?
V>>Еще очень интересно, как под дотнетом можно реализовать GADT/type families/type classes? Чтобы их еще с дотнета можно было использовать ))
V>Да никак, и дотнет тут не причем. В любой системе, ориентированной на бинарное распространение библиотек, языки типа Хаскель не реализуемы.
Почему? Если система поддерживает GADT/type*, то вполне можно устроить интероперабельность. Только это никому не нужно. А в дотнете на эту интероперабельность сильно напирали, а получилось, что "мы покрасим ваш автомобиль в любой цвет, при условии, что этот цвет черный".
Здравствуйте, vshabanov, Вы писали:
V>>>Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. V>>>wpf -- см tcl/tk, V>>>wf -- фигачишь dsl и не паришься, V>>>wcf -- см эрланг, F>> Твои примеры — едва ли аналогичны. Tcl/tk — это вообще смешно сравнивать. Как говаривал тут один участник — фтопку (c) V>Сравни создание GUI на WPF и Tk. Где проще?
За всю страну не скажу, но мне будет проще на любом отличном от tcl/tk. Хотя кто-то возможно его умеет удобно готовить.
Просто твои аппеляции WPF <> Tcl/Tk, WCF <> Erlang и т.п. не сравнимы. Стоит подробнее курить любую из названных крутых аббревиатур.
Да и выражения "фигачишь dsl и не паришься" не совсем отражают действительность. Это так можно про всё сказать, фигачишь и не паришься, а на деле, кроме того, что собственно нужно фигачить, нужно решить, что, чем, где, и как фигачить, и при этом, увы, но паришься! А после того как предшественники "нафигачили" непарясь — вдвойне паришься.
Так что спасибо, но лучше курить мануалы по "низкоуровневым" технологиям, и не парить окружающих.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, vshabanov, Вы писали:
V>>>>Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. V>>>>wpf -- см tcl/tk, V>>>>wf -- фигачишь dsl и не паришься, V>>>>wcf -- см эрланг, F>>> Твои примеры — едва ли аналогичны. Tcl/tk — это вообще смешно сравнивать. Как говаривал тут один участник — фтопку (c) V>>Сравни создание GUI на WPF и Tk. Где проще? F> За всю страну не скажу, но мне будет проще на любом отличном от tcl/tk. Хотя кто-то возможно его умеет удобно готовить. F> Просто твои аппеляции WPF <> Tcl/Tk, WCF <> Erlang и т.п. не сравнимы. Стоит подробнее курить любую из названных крутых аббревиатур.
Чего и вам желаю, для меня это все just smells wrong. Когда я вижу, что примитивный функционал надо реализовывать огромным кол-вом кода (пусть даже большую часть его генерит IDE), я сразу задумываюсь: а что будет, когда мне понадобится что-то, для чего готовых решений нет -- правильно -- придется писать тонну кода.
F> Да и выражения "фигачишь dsl и не паришься" не совсем отражают действительность. Это так можно про всё сказать, фигачишь и не паришься, а на деле, кроме того, что собственно нужно фигачить, нужно решить, что, чем, где, и как фигачить, и при этом, увы, но паришься! А после того как предшественники "нафигачили" непарясь — вдвойне паришься.
Вы видимо dsl-ей не делали. Я лучше подумаю несколько дней и сделаю мелкую библиотечку, которая делает то, что мне нужно, без избыточного мусора. А тот, кто будет эту библиотечку потом поддерживать будет курить мелкий прозрачный сорец, а не огромный фреймворк, в котором черт ногу сломит.
F> Так что спасибо, но лучше курить мануалы по "низкоуровневым" технологиям, и не парить окружающих.
Ваш выбор. Практика показывает, что на хаскеле/эрланге/окемле/tcl-е продукты создаются быстрее, чем на широко разрекламированных технологиях.
Здравствуйте, vshabanov, Вы писали:
V>Чего и вам желаю, для меня это все just smells wrong.
Вот я и говорю, что стоит внимательно изучать, прежде чем фтопку посылать. Да, и в WPF тонн кода нет.
V> Когда я вижу, что примитивный функционал надо реализовывать огромным кол-вом кода (пусть даже большую часть его генерит IDE), я сразу задумываюсь: а что будет, когда мне понадобится что-то, для чего готовых решений нет -- правильно -- придется писать тонну кода.
Когда готовых решений нет, или они не подходят — да, фигачить, таки надо, при чём вне зависимости от технологии/платформы.
V>Вы видимо dsl-ей не делали. Я лучше подумаю несколько дней и сделаю мелкую библиотечку, которая делает то, что мне нужно, без избыточного мусора. А тот, кто будет эту библиотечку потом поддерживать будет курить мелкий прозрачный сорец, а не огромный фреймворк, в котором черт ногу сломит.
Да в той или иной степени делать случалось, т.к. подход в лоб утомителен и поддерживается ещё хуже, из-за этого самого избыточного мусора. Но, что касается прозрачности — тут как повезёт с писателем. Иногда код настолько "мелок" и "прозрачен", что сливается с фоном текста.
F>> Так что спасибо, но лучше курить мануалы по "низкоуровневым" технологиям, и не парить окружающих. V>Ваш выбор. Практика показывает, что на хаскеле/эрланге/окемле/tcl-е продукты создаются быстрее, чем на широко разрекламированных технологиях.
Моя практика показывает, что хаскель/эрланг/окемл/tcl никем не применяется. На этом думаю можно и разойтись.
Здравствуйте, vshabanov, Вы писали:
V>Удобны хаскелл/окемл/эрланг,
Вопросов больше не имею
V> некоторым лисп/
Совсем не имею
V>Посмотрел мельком. Это же тотальный ахтунг. Переусложнение во всем. wpf -- см tcl/tk, wf -- фигачишь dsl и не паришься, wcf -- см эрланг,
Совсем-совсем не имею
V>Dynamic Data -- судя по примерам тот еще монстр, и без IDE с ним наверное не справиться
Слов тоже не осталось
V>(а без IDE он похож на php, хотя не разбирался), посмотри на ur и всякие web фреймворки для того же эрланга
>_<
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, vshabanov, Вы писали:
V>>Чего и вам желаю, для меня это все just smells wrong. F> Вот я и говорю, что стоит внимательно изучать, прежде чем фтопку посылать. Да, и в WPF тонн кода нет.
Да, xml-ное описание gui там очень краткое. Если понадобиться этот гуи генерить, а не рисовать, будет наверное еще короче.
V>> Когда я вижу, что примитивный функционал надо реализовывать огромным кол-вом кода (пусть даже большую часть его генерит IDE), я сразу задумываюсь: а что будет, когда мне понадобится что-то, для чего готовых решений нет -- правильно -- придется писать тонну кода. F> Когда готовых решений нет, или они не подходят — да, фигачить, таки надо, при чём вне зависимости от технологии/платформы.
Вопрос в стоимости фигачения. Тот же хаскелл дает 2-4X сокращение объема сорцов и ~2X прирост производительности труда по сравнению с Java/C*.
F>>> Так что спасибо, но лучше курить мануалы по "низкоуровневым" технологиям, и не парить окружающих. V>>Ваш выбор. Практика показывает, что на хаскеле/эрланге/окемле/tcl-е продукты создаются быстрее, чем на широко разрекламированных технологиях. F> Моя практика показывает, что хаскель/эрланг/окемл/tcl никем не применяется. На этом думаю можно и разойтись.
Если читать только msdn и никуда кроме МС не смотреть, то пожалуй да.
Здравствуйте, vshabanov, Вы писали:
F>> Когда готовых решений нет, или они не подходят — да, фигачить, таки надо, при чём вне зависимости от технологии/платформы. V>Вопрос в стоимости фигачения. Тот же хаскелл дает 2-4X сокращение объема сорцов и ~2X прирост производительности труда по сравнению с Java/C*.
Посльку это говорилось применительно к GUI — то где там применить Хаскел, да ещё с сокращением объемов кода — остаётся загадкой.
Какие-то внутрении части проекта, возможно кто-то осилит и на Хаскеле рисовать. Скажем у меня в проекте, любая попытка использовать Хаскел/Эрланг обернулась бы только переусложнением.
F>> Моя практика показывает, что хаскель/эрланг/окемл/tcl никем не применяется. На этом думаю можно и разойтись. V>Если читать только msdn и никуда кроме МС не смотреть, то пожалуй да.
Пока-что единственный "народный" продукт на erlang — это ejabberd. И что-то я не вижу потока программ, для своей работы которые требовали бы установить OTP.
Точно так же нет потока программ на tcl.
То что экзотики нет в природе и ею пользуются — не говорит об ущербности остальных, особенно когда эти экзотические решения ни одного killer feature не дают.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, vshabanov, Вы писали:
F>>> Когда готовых решений нет, или они не подходят — да, фигачить, таки надо, при чём вне зависимости от технологии/платформы. V>>Вопрос в стоимости фигачения. Тот же хаскелл дает 2-4X сокращение объема сорцов и ~2X прирост производительности труда по сравнению с Java/C*. F> Посльку это говорилось применительно к GUI — то где там применить Хаскел, да ещё с сокращением объемов кода — остаётся загадкой. F> Какие-то внутрении части проекта, возможно кто-то осилит и на Хаскеле рисовать. Скажем у меня в проекте, любая попытка использовать Хаскел/Эрланг обернулась бы только переусложнением.
У нас в проекте вполне себе есть gui. И даже не смотря на то, что используется очень низкоуровневый gtk2hs сокращение кода все равно присутствует. GUI не бывает сам по себе (если это конечно не тупая морда к базе на Delphi), он всегда подразумевает какую-то логику. Вот эта логика, и связь ее с GUI получается заметно короче (тот же Си-шный отладчик, который я недавно делал, занял в два раза меньше времени и в 4 раза меньше сорцов, чем предыдущий вариант на Java, при большей функциональности).
F>>> Моя практика показывает, что хаскель/эрланг/окемл/tcl никем не применяется. На этом думаю можно и разойтись. V>>Если читать только msdn и никуда кроме МС не смотреть, то пожалуй да. F> Пока-что единственный "народный" продукт на erlang — это ejabberd. И что-то я не вижу потока программ, для своей работы которые требовали бы установить OTP. F> Точно так же нет потока программ на tcl. F> То что экзотики нет в природе и ею пользуются — не говорит об ущербности остальных, особенно когда эти экзотические решения ни одного killer feature не дают.
Отсутствие большого кол-ва программ еще не повод отказываться от языка. Если судить только по кол-ву программ, то больше всего их будет на каком-нить коболе/фортране. killer feature -- бОльшая производительность труда.
Здравствуйте, vshabanov, Вы писали:
V>>Да никак, и дотнет тут не причем. В любой системе, ориентированной на бинарное распространение библиотек, языки типа Хаскель не реализуемы.
V>Почему? Если система поддерживает GADT/type*, то вполне можно устроить интероперабельность.
Ты наверно не обратил внимания на сравнение представлений библиотечных модулей. Например, типы классов существуют только для компилятора, отсюда и такое представление библиотек в Хаскеле.
V>Только это никому не нужно.
Сильно ошибаешься. Требование интероперабельности с имеющимся софтом заруливает любые мега-фичи любых языков. Без нормальной, "промышленной" интероперабельности любой язык обречен на весьма узкие ниши, и здесь платформа .Net выступает как неплохой трамплин для любых разработанный под нее языков.
V> А в дотнете на эту интероперабельность сильно напирали, а получилось, что "мы покрасим ваш автомобиль в любой цвет, при условии, что этот цвет черный".
Кривая аналогия. Если уж играть в аналогии, то "при условии, что эта краска из совместимого полимера".
