V> Но пользоваться каким-то новым синтаксисом другого языка еще ни одна IDE не помогала. Синтаксис языка надо знать самому, увы.

по синтаксису помогает даже хороший компилятор, если он не просто сообщает об ошибке, но еще и говорит какой терм ожидается дальше.

Хорошая же IDE сообщает тоже самое на лету.

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


I>Пока что очевиден такой тренд — ООП кочует в функциональные языки, хотя казалось бы, "там будут совсем другие проблемы". Ан нет, наверное функционалистам нравится решать задачу, от чего наследовать прямоугольник.

"ООП кочует в функциональные языки" это старая тенденция, так например появился OCaml. При этом ООП там так "немножко" мутировал что наследование там только сахар и по сути не нужно при структурной типизации то. Кстати задача "от чего наследовать прямоугольник" там довольно бессмысленна

А сейчас другая тенденция функциональные языки пытаются натянуть на ООП платформы, это и F# и Scala, получается по моему достаточно коряво и угловато, но тоже лучше чем ничего.

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

V>> Но пользоваться каким-то новым синтаксисом другого языка еще ни одна IDE не помогала. Синтаксис языка надо знать самому, увы.
DG>по синтаксису помогает даже хороший компилятор, если он не просто сообщает об ошибке, но еще и говорит какой терм ожидается дальше.

Хы, дальше...
Знать бы с какого начать...

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

I>Почему то "открыть дверь" предлагают решить только в ООП, и никто не захотел показать решение той же задачи в функциональном.

I>Как уже предлагалось — напиши грамотный мега-uber-рич-эдит на хаскеле или F# и что бы без ооп, да так, что бы его можно было кинуть на форму одной кнопкой и юзать так же, как и любой другой рич эдит.


I>Если не нравится рич-эдит, посмотри в те задачи, которые типично решаются с помощью С++, например видео или звук.
Или, например, роутинг пакетов. Название "эрланг" вам что-нибудь говорит?

I>Предложи качественное решение на функциональном языке да без императивщины, используюя чисто иммутабельные конструкции, что бы перформанс был в норме, потребление памяти было не хуже чем у нативного кода и тд и тд.
Отож.
I>Пока что очевиден такой тренд — ООП кочует в функциональные языки, хотя казалось бы, "там будут совсем другие проблемы". Ан нет, наверное функционалистам нравится решать задачу, от чего наследовать прямоугольник.
Пока что очевиден такой тренд — ООП как таковое остановилось в развитии примерно тридцать лет назад. С тех пор все успехи связаны с мультипарадигменностью и развитием системы типов; в частности — в функциональном направлении.

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

I>>Если не нравится рич-эдит, посмотри в те задачи, которые типично решаются с помощью С++, например видео или звук.
S>Или, например, роутинг пакетов. Название "эрланг" вам что-нибудь говорит?

Если ты хочешь сказать, что задача(требования+ограничения) определяет инструмет, то это именно то о чем я и говорю.

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

I>>Если не нравится рич-эдит, посмотри в те задачи, которые типично решаются с помощью С++, например видео или звук.
S>Или, например, роутинг пакетов. Название "эрланг" вам что-нибудь говорит?

В алгоритмах роутинга я кое что понимаю, все таки >10 лет в телекоммуникациях. В задаче про которую ты намекаешь (роутингов вообще много и самых разных), кстати говоря, требуется распределенный процессинг. А если вдруг надо считать роутинг на одном проце и в ограниченом объеме памяти, что вобщем частый случай, то эрланг сливает нещадно и ему не помогут никакие плюшки.

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

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

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

I>>Если не нравится рич-эдит, посмотри в те задачи, которые типично решаются с помощью С++, например видео или звук.
S>Или, например, роутинг пакетов. Название "эрланг" вам что-нибудь говорит?

Кстати говоря, я вот видел и кое где даже поучавствовал в написании алгоритмов роутинга (С++, джава и C#). А ты можешь похвастаться тем, что написал скажем хотя бы ричэдит на хаскеле ну или какую нибудь насквозь императивную задачу на том же хаскеле или другом функциональном языке ?

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

T>Если ты хочешь сказать, что задача(требования+ограничения) определяет инструмет, то это именно то о чем я и говорю.
Задача может определять инструмент.
Вопрос зачастую сводится к формулировке задачи.
И то, что задача в принципе решается некоторым методом, не означает, что именно этим методом её и надо решать.
Именно об этом фанаты DSL пишут в этом топике. А вовсе не о том, что ООП вообще плохое, хотя именно это вы с Ikemfula пытаетесь меня заставить доказать.

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

I>Кстати говоря, я вот видел и кое где даже поучавствовал в написании алгоритмов роутинга (С++, джава и C#). А ты можешь похвастаться тем, что написал скажем хотя бы ричэдит на хаскеле ну или какую нибудь насквозь императивную задачу на том же хаскеле или другом функциональном языке ?
Я правильно понимаю, что аргументы у вас кончились, и вы решили перейти на обсуждение моей личности и прочую пенисометрию?
Если да, то я лучше перейду на обсуждение вашей орфографии

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

DG>>по синтаксису помогает даже хороший компилятор, если он не просто сообщает об ошибке, но еще и говорит какой терм ожидается дальше.
V>Хы, дальше...
V>Знать бы с какого начать...

Дык библиотеками та же фигня. Для старта надо просто глянуть примеры.

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

I>>Кстати говоря, я вот видел и кое где даже поучавствовал в написании алгоритмов роутинга (С++, джава и C#). А ты можешь похвастаться тем, что написал скажем хотя бы ричэдит на хаскеле ну или какую нибудь насквозь императивную задачу на том же хаскеле или другом функциональном языке ?
S>Я правильно понимаю, что аргументы у вас кончились, и вы решили перейти на обсуждение моей личности и прочую пенисометрию?
S>Если да, то я лучше перейду на обсуждение вашей орфографии

Ну вот снова "гранаты не той системы".

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

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

Если так, то Эрланг должны были изобрести в 1973 году вместо 1987, потому что в 93 в нем появились распределенные вычисления и с тех пор он именно для того и используется. Собственно ни для чего другого он толком и не пригоден и потому болтается на грани стат-погрешности.

V>Знать бы с какого начать...

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

Для примера, C#-компилятор в этом хуже.

hz kak pisat

//error: A namespace cannot directly contain members such as fields or methods

т.е. надо догадаться, что ожидаются термы namespace, class и т.д.

дальше чуть лучше

class hz kak pisat

//(1,10,1,13): error CS1514: { expected

class hz {kak pisat

//(1,20,1,21): error CS1002: ; expected

class hz {kak pisat;

//(1,21,1,22): error CS1513: } expected

синтаксические ошибки закончились, дальше надо разбираться со смыслом

class hz {kak pisat;}

//(1,12,1,15): error CS0246: The type or namespace name 'kak' could not be found (are you missing a using directive or an assembly reference?)

ps
вообще, есть такой забавный метод написания кода, как error driven. С помощью этого метода, при хороших утилитах можно писать код, даже не зная синтаксиса и семантики, а изучая их на ходу на основе текста ошибок.

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

T>>Если ты хочешь сказать, что задача(требования+ограничения) определяет инструмет, то это именно то о чем я и говорю.
S>Задача может определять инструмент.
S>Вопрос зачастую сводится к формулировке задачи.
S>И то, что задача в принципе решается некоторым методом, не означает, что именно этим методом её и надо решать.
S>Именно об этом фанаты DSL пишут в этом топике. А вовсе не о том, что ООП вообще плохое, хотя именно это вы с Ikemfula пытаетесь меня заставить доказать.

У тебя должно быть хорошее объяснение, почему насквозь императивное ООП отлично влезает в те области, которые, казалось бы, на раз покрываются возможностями функциональщины, МП и ДСЛ. И наоборот — функциональщина, МП и ДСЛ почему то болтаются где то на той грани, дальше которой ими можно пренебречь и хорошо живет только в очень, очень специализиваных нишах, можно даже сказать вырожденых случаях, где нужно решать одну единственную задачу, вдобавок ко всему жестко прижестко изолированую.

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

T>У тебя должно быть хорошее объяснение, почему насквозь императивное ООП отлично влезает в те области, которые, казалось бы, на раз покрываются возможностями функциональщины, МП и ДСЛ. И наоборот — функциональщина, МП и ДСЛ почему то болтаются где то на той грани, дальше которой ими можно пренебречь и хорошо живет только в очень, очень специализиваных нишах, можно даже сказать вырожденых случаях, где нужно решать одну единственную задачу, вдобавок ко всему жестко прижестко изолированую.

Кстати, недавно как-то обратил внимание на один забавный нюанс в этой области. Особенно забавный в контексте местных мыслей о продвижение МП. Обычно при этом подразумевают всякие маргинальные языки... Но ведь настоящее МП есть в самом мейнстримовом языке! Макросы в C/C++ — это же прямое МП. Ну т.е. конечно их частенько и для ерунды (типа объявления констант и т.п.) используют, но можно и именно для генерации кода. Я например только так и использую — очень удобно для всяких там тестов и т.п.

А теперь внимание! Смотрим большинство учебников или советов по языку и видим что там выдвигается жёсткий лозунг: "Макросы — зло! Стараться не использовать!".

Более того, этому лозунгу следуют везде. Помнится в прошлом для организации вещей типа обработки сообщений была популярна техника составления таблиц обработчиков с помощью макросов. Сейчас же в большинстве библиотек это переписано (!) на техники типа сигнал/слот (причём через средства самого языка, а не через извращения как в устаревшей Qt).

И таких примеров не мало. Т.е. получается что на самом деле в мейнстриме всё это время происходил плавный отказ от средств МП в пользу встраивания необходимых инструментов в сам язык.

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

Да, с основами C# вроде бы несложно. Если не лезть в LINQ, например, бо там ни одно Err-DD не поможет.
Ну и с таким языком, как плюсы, этот способ не прокатит, ес-но. ))

============
Далее сугубо ИМХО и наблюдения.

Вменяемая библиотека — это самодокументируемая штука. Браузер АПИ (компонентов) дает неплохое представление, если наружу торчат адекватные идентификаторы + очевидные типизированные (обязательно!) зависимости. Для старта работы с такими либами действительно достаточно несложных примеров и далее можно двигаться постепенно, каждый раз генерируя пользу, бо достаточно изучать ровно те аспекты, либы которые нужны в реальной текущей работе.

В то же время с синтаксисом языка всё малость сложнее, его надо знать практически ВЕСЬ, чтобы хоть что-то полезное делать. В этом соль. Изучать язык постепенно можно, но что-то полезное делать нельзя до более-менее хорошего изучения. Увы. Для сравнения, на изучение синтаксиса современного языка до уровня, достаточного до писанины чего-то полезного я бы дал неделю минимум. И не врите мне тут про оценку в единицы часов, если речь о написании чего-то полезного, бо это как раз время "втыкания" в библиотеку, а не в язык. А на языке за эту неделю изучения (а то и больше для некоторых языков) надо очень много пописать и попробовать при этом всякого в нём, чтобы "прочувствовать" его силы и слабости. Т.е. это совсем другой уровень и трудоемкость освоения, чем требуется для либы. ИМХО, потому что язык — это самый нижний базис для итогового комбинаторного сочетания сущностей сколь угодно высокого уровня, а либа сама тебя ограничивает в сценариях её применения и там редко выше 2-3-х уровней зависимостей. Т.е. тьфу, несмотря на обилие идентификаторов и функционала.

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

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

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

_>А теперь внимание! Смотрим большинство учебников или советов по языку и видим что там выдвигается жёсткий лозунг: "Макросы — зло! Стараться не использовать!".
Макросы С/С++ зло. Согласен на 100%.

_>И таких примеров не мало. Т.е. получается что на самом деле в мейнстриме всё это время происходил плавный отказ от средств МП в пользу встраивания необходимых инструментов в сам язык.
Ну, так мы такое МП и делаем. Чтобы в язык можно было всё, что нужно встроить.

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

WH>Макросы С/С++ зло. Согласен на 100%.

А я с удовольствием использую. Например для тестов удобно и ещё для некоторых особых случаев. В общем для генерации одинакового кода для разных сущностей.

WH>Ну, так мы такое МП и делаем. Чтобы в язык можно было всё, что нужно встроить.

1. В какой язык?
2. Вообще то на макросах C/C++ как раз микро DSL и получались (те же самые таблицы обработчиков)... Но от них предпочли отказаться в пользу самых классических конструкций (типа button->Connect(..., OnClick)).

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

WH>>Макросы С/С++ зло. Согласен на 100%.
_>А я с удовольствием использую. Например для тестов удобно и ещё для некоторых особых случаев. В общем для генерации одинакового кода для разных сущностей.
Конечно, если ничего другого нет, то я и сам использую.
Но макросы в С/С++ очень плохие.

WH>>Ну, так мы такое МП и делаем. Чтобы в язык можно было всё, что нужно встроить.
_>1. В какой язык?
В любой.

_>2. Вообще то на макросах C/C++ как раз микро DSL и получались (те же самые таблицы обработчиков)... Но от них предпочли отказаться в пользу самых классических конструкций (типа button->Connect(..., OnClick)).
Далеко не всегда так можно сделать.