Автор Тема: Идеальный ЯП  (Прочитано 41832 раз)

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #15 : Февраль 27, 2011, 08:10:44 pm »
У меня есть конкретное понимание, насколько наличие доп. фич увеличит производительность разработки. И соотнесение этого с тратой даже 2-3 человеко-месяцев на разработку. И факт в том, что это неоправдано (хотя было бы приятно это получить когда-нибудь, конечно, но только в удобном виде, в парадигме "текст-как-интерфейс", а не в ужасном и устаревшем стиле оконно-формочных студий).

У Вас - только сотрясания воздуха о том, что нет чего-то, что есть в других системах, и высосанные из пальца предположения о том, что это как-то значительно влияет на производительность труда.

При наличии тысяч разрабов лидеры индустрии могут себе позволить нашпиговать продукт массой мелких примочек, вообще не задумываясь о том, насколько это нужно.
Альтернативным сообществам пытаться гоняться за лидерами в этих мелочах, вместо того, чтобы решать реальные задачи, - пустая трата времени.
Чью производительность труда - проф. программеров ? Клал я на это - поскольку не вижу достаточных оснований использования ББ ими, кроме just for fun. Я говорю про ту часть которую ЗНАЮ - это студенты перваши, которые не обучались программированию..и преподавателей...

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #16 : Февраль 27, 2011, 08:34:00 pm »
Собственных впечатлений об особенностях проекта при размере свыше сотни тысяч строк у меня действительно нет.

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

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #17 : Февраль 27, 2011, 08:43:38 pm »
Собственных впечатлений об особенностях проекта при размере свыше сотни тысяч строк у меня действительно нет.

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

Это уже другой разговор.. Даже на форуме у вас появляются люди которые хотят изменить ситуацию...вспомните года полтора назад. id_ler кажется...предлагал свои услуги - у меня после чтения той ветки остался негатив к сообществу и Инфо21, Соломенников, что-то пробовал делать...Роман М....- надо просто для начала четко ставить проблему...

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #18 : Февраль 27, 2011, 08:48:22 pm »
Понимаю, что смысла нет не имея соответствующего опыта. Можно только либо нафантазировать, либо сделать слепо по аналогии.

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

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #19 : Февраль 27, 2011, 08:58:57 pm »
Понимаю, что смысла нет не имея соответствующего опыта. Можно только либо нафантазировать, либо сделать слепо по аналогии.

А смысл в том (мог бы быть), что если проект писан в стиле маленького проекта и на соответствующем инструментарии, то он очень и очень плохо масштабируется. Т.e. будут болезни роста, а поскольку в инструменте (языке) не предусмотрены механизмы для проектов реально большого размера, придется по сути проект переписывать. И инструмент (язык) перепроектировать. В несколько итераций. Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.
Вы про что говорите про ББ или Идеальный ЯП?

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #20 : Февраль 27, 2011, 09:09:13 pm »
Мы скорее говорим про различие схемы разработки растущего проекта при использовании КП и Идеального ЯП :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #21 : Февраль 27, 2011, 09:14:06 pm »
Мы скорее говорим про различие схемы разработки растущего проекта при использовании КП и Идеального ЯП :-)
Предлагаю сообщения связанные с развитием и доводкой ББ развести по новым веткам - таки ББ это не язык и тем более не Идеальный ЯП (что бы не говорили его адепты ИМХО)

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #22 : Февраль 28, 2011, 09:44:48 pm »
Это уже другой разговор.. Даже на форуме у вас появляются люди которые хотят изменить ситуацию...вспомните года полтора назад. id_ler кажется...предлагал свои услуги - у меня после чтения той ветки остался негатив к сообществу и Инфо21, Соломенников, что-то пробовал делать...Роман М....- надо просто для начала четко ставить проблему...

Золотые слова - надо чётко ставить проблему. Это не так просто. В правильной постановке, неспроста говорят, большая часть решения :)

Лично я, например, не могу в данный момент поставить задачи такого типа, потому что у меня нет проблемы, на которой я бы представил, что там именно нужно. Просто делать "как у других" - это фуфло. Нужен какой-то "пробный камень", на котором это можно сделать. Чтобы это понять, тоже нужно время; так что просто взять и "поставить задачу" не всегда получается.

У нас внутри коллектива есть набор доп. инструментов работы с кодом, но всё это делалось под реальные нужды и постепенно. Когда возникает понимание - можно сразу поставить задачу.
Могу сказать, что ничего похожего на "Студии" от реальных нужд не возникает даже близко. Возникает другое и другим образом реализуемое.

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #23 : Февраль 28, 2011, 09:50:10 pm »
Чью производительность труда - проф. программеров ? Клал я на это - поскольку не вижу достаточных оснований использования ББ ими, кроме just for fun. Я говорю про ту часть которую ЗНАЮ - это студенты перваши, которые не обучались программированию..и преподавателей...

Для первашей нормальный препод - не нытик и понявший "фишку" компонентной расширяемой системы - за день-два слепил бы всё, что нужно именно его первашам. В чём проблема, не было ясно никому, с момента Вашего прихода на ОберонКоре.

(Казалось, что Ваши претензии в том, что "всё не так, как у других", с Вами спорили... - потом выяснилось, что Ваши претензии не в этом.)

Илья Ермаков

  • Full Member
  • ***
  • Сообщений: 177
    • Просмотр профиля
    • OberonCore
Re:Идеальный ЯП
« Ответ #24 : Февраль 28, 2011, 09:53:12 pm »
А смысл в том (мог бы быть), что если проект писан в стиле маленького проекта и на соответствующем инструментарии, то он очень и очень плохо масштабируется. Т.e. будут болезни роста, а поскольку в инструменте (языке) не предусмотрены механизмы для проектов реально большого размера, придется по сути проект переписывать. И инструмент (язык) перепроектировать. В несколько итераций. Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.

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

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #25 : Март 01, 2011, 12:57:02 am »
Поэтому если предполагается, что проект будет расти, хорошо бы использовать сразу язык адекватный этому самому росту. Если не будет, то да, тут можно и питон взять какой-нибудь.

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

Все равно code base будет расти... Проблемы роста те же.

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #26 : Март 01, 2011, 04:08:39 pm »
Для меня идеальный ЯП - который позволяет описывать исследуемую систему без искажений, т.е. писать программу на нем и разбираться в ней - эквивалентно  понятию описывать систему и разбираться с системой.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #27 : Март 01, 2011, 04:10:44 pm »
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Идеальный ЯП
« Ответ #28 : Март 01, 2011, 04:17:33 pm »
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
не так сурово...  :) я человек скромный и понимаю что весь мир мне не обьять... по мне хватает качественной (близкой к общепринятой) реализации базовых понятий алгоритм, переменная, тип, субалгоритм,  ветвление, присваивание, циклический процесс.. поддержка ООП . Почти Оберон.. короче .  ;)

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Идеальный ЯП
« Ответ #29 : Март 01, 2011, 04:21:28 pm »
Тогда получается язык под задачу, под каждую задачу/систему (или класс задач) пишется свой DSL. И вот тут то и всплывает призрак лиспа… :-)
Вот-вот.
Осталось только сделать для него возможность менять синтаксис так, как будет удобно для решаемой задачи, не теряя при этом возможности удобной манипуляций с AST...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…