Вышла (http://tech.groups.yahoo.com/group/eiffel_software/message/1... версия 6.6 IDE для языка Eiffel (http://ru.wikipedia.org/wiki/Eiffel_%28programming_lang... - EiffelStudio. Eiffel - это объектно-ориентированный язык, поддерживающий технологию проектирования по контракту (http://sergeyteplyakov.blogspot.com/search/label/Design%....
Основные характеристики языка и среды программирования:- Кроссплатформенная реализация - существуют версии EiffelStudio для FreeBSD, Linux, OpenBSD, Solaris (в том числе и Solaris SPARC), Windows- Автоматическая сборка мусора- Технология "Проектирование по контракту" (http://en.wikipedia.org/wiki/Design_by_contract) - предусловия, постусловия, инварианты поддерживаются непосредственно самим компилятором языка (не требуются дополнительные инструменты и библиотеки)- Поддержка множественного наследования; разрешение конфликта имен (компоненты, наследованные от разных классов имеют одно и тоже имя) путем переименовани...
URL: http://docs.eiffel.com/book/eiffelstudio/release-notes-eiffe...
Новость: https://www.opennet.ru/opennews/art.shtml?num=26795
А недостатки у него какие?
первое, на вскидку - бинарники тяжеловаты, и в 6.4 во всяком случае компиляция долго длилась. Ну, и не привычно конечно, так уж получилось что современные методологии на яву заточены.
расскажите, как впечатления, кто с этим работал? Я как-то одно время пытался его серьёзно освоить, но там слишком уж непривычная для наших программеров концепция, так и не понял как на нём с этими людьми что-то сделать можно было бы. Может был у кого положительный опыт?
Для начала стоит изучить проектирование по контракту - ключевая, на мой взгляд, идея Eiffel. На русском можно почитать недавно вышедший цикл статей в блоге:
http://sergeyteplyakov.blogspot.com/search/label/Design%...
Безусловно, стоит прочесть классическую книгу Бертрана Мейера "Объектно-ориентированное конструирование программных систем" (на русском). И более доступную книгу для студентов того же Мейера: Bertrand Meyer "Touch of Class: Learning to Program Well with Objects and Contracts" (пока только на английском, но к концу года обещают перевести на русский).
Вот краткий обзор языка:
http://eao197.narod.ru/better_language/languages/eiffel/0_ov...
Мое личное мнение об этом языке (ИМХО) - идеальный язык для обучения программированию. И последняя книга "Touch of Class" только еще больше меня убеждает в этом мнении.
Да, спасибо, Мейера тоже читал пару лет назад, и про ипользование BON тоже, очень заинтересовался, кое-что пробовал сам писать тоже. Полностью согласен что это идеальный язык чтобы учиться программировать правильно. Вот только это язык на мой взгляд не для одиночек, его сила в решении проблем работы в комманде и разработки очень сложных систем, и вот тут у меня как раз незадача: люди с которыми я работаю вместе уже имеют определённые знания и опыт, но пришел к ним этот опыт по сути из явы, и в институте они UML изучали а не BON, и думают они поэтому в стиле явы, рады что с юнит-тестами через пень-колоду разобрались и на большее не замахваются. Не знаю я пока как можно было-бы этих людей заинтересовать с Eiffel поработать, вот и вопрос - может у кого-нибудь есть положительный опыт реальных проектов на этом языке, не 20-летней давности, а с учётом современных реалий? Об этом было бы очень интересно почитать.
>Вот только это язык на мой взгляд не для одиночек, его сила в решении проблем работы в комманде и разработки очень сложных систем,Любой язык можно использовать и в "одиночестве", и в команде.
Тут скорее всего имеет место стадное чувство и страх что-то в одиночестве самому начинать.Кроме того. А почему нельзя использовать разные языки в одной команде. Ну да, религия не позволяет.
Однако основное назначение всех абстрактных объектно-контрактных-супер-пупер-проблемно-ориентированных языков как раз и заключается в том, что реализацию интерфейсов, моделей или чего там еще можно делать на множестве других языков. Предоставив тем самым другим любителям других языков просто интегрироваться в проект.
>и вот тут у меня как раз незадача: люди с которыми я работаю вместе уже имеют определённые знания и опыт,
Незадача заключается в том, что вместо того, чтобы самостоятельно изучить то, что показалось перспективным, здесь имеет место непреодолимое желание убедить других делать то же самое.
Ярко выраженное стадное чувство.>Не знаю я пока как можно было-бы этих людей заинтересовать с Eiffel поработать,
Может проще найти уже заинтересованных?
Вот и получается замкнутый круг - как заинтересовать других людей осваивать то, что самостоятельно не освоено и отдача от этого не получена - а раз другие это осваивать не хотят, то самому осваивать страшно.
>вот и вопрос - может у кого-нибудь есть положительный опыт реальных проектов на этом языке,
Т.е. без чужого "положительного опыта" ну просто никак.
А разве опыта тех, кто это создал, поддерживает и развивает недостаточно?>не 20-летней давности, а с учётом современных реалий? Об этом было бы очень интересно почитать.
Ну, если этот язык до сих пор существует и развивается, наверное "современные реалии" в нем как-то учитываются.
Важно еще не перепутать эти самые "современные реалии" с банальными стереотипами. А то как всегда "давайте сделаем это как-то по-другому, но только так, чтобы все оставалось по-прежнему".
А еще не забывать, что много "новое" и "современнореальное" часто оказывается "хорошо забытым старым".
>Любой язык можно использовать и в "одиночестве", и в команде.
>Тут скорее всего имеет место стадное чувство и страх что-то в одиночестве
>самому начинать.я к счастью работал с достаточным количеством языков, чтобы не бояться стадного чувства. Как раз айфель на мой взгляд - другой случай. Но может быть конечно я в этот раз ошибаюсь.
>
>Кроме того. А почему нельзя использовать разные языки в одной команде. Ну
>да, религия не позволяет.у уже ниже ответил
>
>Незадача заключается в том, что вместо того, чтобы самостоятельно изучить то, что
>показалось перспективным, здесь имеет место непреодолимое желание убедить других делать то
>же самое.
>Ярко выраженное стадное чувство.ещё раз, айфель - особый случай, он был создан чтобы решать спецефические задачи, которые без наличия "стада" обычно не встречаются
>
>Может проще найти уже заинтересованных?да, это было бы не плохо. Поищу интересный опенсорсный проект. Серьёзно.
>
>Т.е. без чужого "положительного опыта" ну просто никак.
>А разве опыта тех, кто это создал, поддерживает и развивает недостаточно?да, опыт тех кто его создал почему-то не убеждает. Создалось впечатление что язык жив больше ради поддержки существующих проектов, ну и кое-где его студентам дают изучать. Не нашёл я на нём пока достаточно активных новых проектов.
>я к счастью работал с достаточным количеством языков, чтобы не бояться стадного чувства. Как раз айфель на мой взгляд - другой случай. Но может быть конечно я в этот раз ошибаюсь.
>ещё раз, айфель - особый случай, он был создан чтобы решать спецефические задачи, которые без наличия "стада" обычно не встречаютсяВсе ясно. Для вас "стадо" и "команда" примерно одно и то же. В этом и проблема.
В стаде все стремятся делать одно и то же, и смотрят друг на друга.
В команде каждый занимается своим делом и по-своему. Возможно даже на своем языке, и результаты объединяются для достижения максимальной отдачи за счет синергетического эффекта.Так что вам скорее всего нужно просто поискать настоящую команду, а не стадо, и поучиться в ней взаимодействовать. И дело даже не в конкретном языке, а в самом мышлении.
>да, опыт тех кто его создал почему-то не убеждает.
Ну вот очередное подтверждение наличия "замкнутого круга". Вы оказывается сами не достаточно убеждены. Но при этом пытаетсь убедить других. Видимо чтобы они это сами начали, и чтобы помогли убедиться вам.
>да, это было бы не плохо. Поищу интересный опенсорсный проект. Серьёзно.
>Создалось впечатление что язык жив больше ради поддержки существующих проектов, ну и кое-где его студентам дают изучать. Не нашёл я на нём пока достаточно активных новых проектов.В том-то и вопрос, что вы ожидаете найти. Видимо что-то похожее на то, что делается на тех языках, на которых пишут "другие", которых вам никак не удается убедить.
>[оверквотинг удален]
>В стаде все стремятся делать одно и то же, и смотрят друг
>на друга.
>В команде каждый занимается своим делом и по-своему. Возможно даже на своем
>языке, и результаты объединяются для достижения максимальной отдачи за счет синергетического
>эффекта.
>
>Так что вам скорее всего нужно просто поискать настоящую команду, а не
>стадо, и поучиться в ней взаимодействовать. И дело даже не в
>конкретном языке, а в самом мышлении.
>Спасибо, хорошая мысль.
>>да, опыт тех кто его создал почему-то не убеждает.
>
>Ну вот очередное подтверждение наличия "замкнутого круга". Вы оказывается сами не достаточно
>убеждены. Но при этом пытаетсь убедить других. Видимо чтобы они это
>сами начали, и чтобы помогли убедиться вам.
>нет, это уже врядли. Но на данный момент для меня интересна общая продуктивность нашей комманды.
>
>В том-то и вопрос, что вы ожидаете найти. Видимо что-то похожее на
>то, что делается на тех языках, на которых пишут "другие", которых
>вам никак не удается убедить.нужно подумать.
> Я как-то одно время пытался его серьёзно освоить, но там слишком уж непривычная для наших программеров концепция,Что значит наши-ненаши?
В программировании нет наших, есть способные и неспособные. А также уровень свободы мышления от стереотипов и шаблонов.> так и не понял как на нём с этими людьми что-то сделать можно было бы.
Так вы хотели новый язык освоить или что-то "сделать с этими людьми".
Можно например освоить язык и создать на нем ПО, которое что-то "делает с этими людьми". А не дожидаться, когда "эти люди" окажутся способными что-то "сделать", чуть более отличное от того, к чему они привыкли.
>[оверквотинг удален]
>мышления от стереотипов и шаблонов.
>
>> так и не понял как на нём с этими людьми что-то сделать можно было бы.
>
>Так вы хотели новый язык освоить или что-то "сделать с этими людьми".
>
>Можно например освоить язык и создать на нем ПО, которое что-то "делает
>с этими людьми". А не дожидаться, когда "эти люди" окажутся способными
>что-то "сделать", чуть более отличное от того, к чему они привыкли.
>Для начала, для чего нам это нужно: я веб-разработчик, мы делаем на php довольно сложные системы под заказ, и некоторые вещи было бы не плохо вынести в отдельный процесс и скомпилировать - кэш, спецефический поиск итд.. Для таких вещей на мой взгляд айфель подошёл бы идеально - производительность сравнима с C, а качество кода будет значительно выше. Потом, на мой взгляд, опыт "разработки по контракту" и в php не помешал бы, но для этого нужно его сначала на самом eiffel получить - сделать на нём какие-то пробные пректы и посмотреть как эта система работает, что там удобно а что нет. Вот пока и не знаю как заинтересовать коллег им заняться, это не студенты зелёные и стереотипы у них уже давно устоялись. Найти других - тоже конечно выход, но пока не реальный.
Ага, PHP + кеш на эйфеле - это будет нечто :-)))))
Потом придётся всё заново переписывать, 100%
> http://habrahabr.ru/blogs/development/95079/- да ладно, я в курсе :)
На самом деле задача скорее в том чтобы приделать к проекту memcache, или самим написать демона который знает о наших объектах. На C писать такие вещи действительно глупо, на яве врядли особо что-то выиграешь. Ещё раз, это пока только идея для пилот-проекта чтобы попробовать eiffel в реальных условиях.
Мне приходилось очень много иметь дел с Eiffel хотя бы в рамках прохождения кучи курсов в ETH Zurich. Скажем так: удобно. Такого гибкого и красивого ООП пока нет ни у кого, однако программирование по контракту больше похоже на TDD в плане организации процесса. Наверное это идеальный язык для TDD. Контракты красивы, но если использовать их как положено, то около 80% кода будут составлять именно эти однотипные соглашения.Производительность, кстати, сравнима с С только в случае генерирования окончательного кода, но там, сюрприз, эти славные require и ensure частично отключаются, так что смысла в них маловато на самом деле.
>Производительность, кстати, сравнима с С только в случае генерирования окончательного кода, но
>там, сюрприз, эти славные require и ensure частично отключаются, так что
>смысла в них маловато на самом деле.да, я в курсе, я исхожу из того что в production их оставлять не очень-то разумно
>Производительность, кстати, сравнима с С только в случае генерирования окончательного кода, но там, сюрприз, эти славные require и ensure частично отключаются, так что смысла в них маловато на самом деле.Это и не удивительно, ведь проверка инвариантов, пост- и предусловий требует определенных временных затрат. По оценкам, при мониторинге контрактов теряется примерно 25% скорости по сравнению с отключенными проверками.
>Для начала, для чего нам это нужно: я веб-разработчик, мы делаем на php довольно сложные системы под заказ, и некоторые вещи было бы не плохо вынести в отдельный процесс и скомпилировать - кэш, спецефический поиск итд.. Для таких вещей на мой взгляд айфель подошёл бы идеально - производительность сравнима с C, а качество кода будет значительно выше. Потом, на мой взгляд, опыт "разработки по контракту" и в php не помешал бы, но для этого нужно его сначала на самом eiffel получить - сделать на нём какие-то пробные пректы и посмотреть как эта система работает, что там удобно а что нет. Вот пока и не знаю как заинтересовать коллег им заняться, это не студенты зелёные и стереотипы у них уже давно устоялись. Найти других - тоже конечно выход, но пока не реальный.Вы просто напоминаете сами программу, которую запрограммировали.
Что бы что-то освоить самому, нужно обязательно убедить в этом других.Ну если вам интуиция подсказывает, что перечисленные вами технологии могут быть успешно использованы в ваших коллективных проектах, ну так и внедрите их самостоятельно. И просто интегрируйтесь с уществующим кодом на других языках.
Или вы не знаете, что такое системная интеграция?
>
>Вы просто напоминаете сами программу, которую запрограммировали.
>Что бы что-то освоить самому, нужно обязательно убедить в этом других.
>
>Ну если вам интуиция подсказывает, что перечисленные вами технологии могут быть успешно
>использованы в ваших коллективных проектах, ну так и внедрите их самостоятельно.
>И просто интегрируйтесь с уществующим кодом на других языках.
>
>Или вы не знаете, что такое системная интеграция?видимо боюсь оказаться в положении эзотерика, сваявшего какую-то заумь, с которой никто не хочет разбираться пока она работает, а потом её просто переписывают заново :)
>видимо боюсь оказаться в положении эзотерика, сваявшего какую-то заумь, с которой никто не хочет разбираться пока она работает, а потом её просто переписывают заново :)А это смотря, что вам важнее.
Делать то, что работает, и осваивать для этого такие инструменты, которые более всего подходят именно вам, а не другим, и которые помогают именно вам самому достичь максимальной производительности.
Или чтобы другие разбирались, как именно работает то, что вы делаете.
Боитесь что перепишут? Но ведь если вы нашли инструмент, который даст вам большую производительность, тогда переписывать то, что вы с его помощью сделаете обойдется другим гораздо дороже.
А если вы все-таки боитесь, что вы не достигнете более высокой производительности - значит вы на самом деле сомневаетесь либо в перспективности нового направления, либо в собственных способностях. Отсюда и подсознательное желание привлечь к этому других, поскольку в одиночку вы просто боитесь рискнуть.
>[оверквотинг удален]
>Или чтобы другие разбирались, как именно работает то, что вы делаете.
>
>Боитесь что перепишут? Но ведь если вы нашли инструмент, который даст вам
>большую производительность, тогда переписывать то, что вы с его помощью сделаете
>обойдется другим гораздо дороже.
>
>А если вы все-таки боитесь, что вы не достигнете более высокой производительности
>- значит вы на самом деле сомневаетесь либо в перспективности нового
>направления, либо в собственных способностях. Отсюда и подсознательное желание привлечь к
>этому других, поскольку в одиночку вы просто боитесь рискнуть.А можно Вам порекомендовать другой замечательный язык, форт (forth) называется ? Я им одно время очень увлекался, преинтереснейшая вещь ;)
>А можно Вам порекомендовать другой замечательный язык, форт (forth) называется ? Я им одно время очень увлекался, преинтереснейшая вещь ;)А почему вы решили, что для меня forth нуждается в рекомендациях?
>>А можно Вам порекомендовать другой замечательный язык, форт (forth) называется ? Я им одно время очень увлекался, преинтереснейшая вещь ;)
>
>А почему вы решили, что для меня forth нуждается в рекомендациях?да так, к слову просто, немножко психологии ;)
>да так, к слову просто, немножко психологии ;)Ну так я с этого и начал, что жедание убеждать других вмето того, чтобы осваивать самому - это проблема чисто психологическая, и к конкретному языку не относится.
>>да так, к слову просто, немножко психологии ;)
>
>Ну так я с этого и начал, что жедание убеждать других вмето
>того, чтобы осваивать самому - это проблема чисто психологическая, и к
>конкретному языку не относится.извините, проблема из области психологии - утверждать, что подход в освоении (не изучении, а именно освоении) языка от самого языка не зависит. Если я Вас правильно понял конечно. Поэтому привёл в пример forth , как противоположность к eiffel - это ведь тоже язык с очень интересными идеями, но имеет смысл если программа небольшого объёма и пишет её на 100% один человек и больше никто в его код никогда не полезет. А eiffel на мой взгляд ничего не даёт программисту-одиночке, кроме кучи дополнительных формальностей. Которые в принципе можно опустить, и тогда это будет ещё одна альтернатива плюсам и яве, разве что несколько более тяжеловесная. Ещё раз, для меня не стоит вопрос в изучении нового языка, я знаю и работал на forth, c, pascal, perl, php, java, изучал в свое время cobol, oberon, unicon чтобы попробовать, да чем только не приходилось заниматься за последние лет пятнадцать. Но в любом случае, спасибо за совет, попробую поискать интересные проекты в сети чтобы поработать с ними вместе.
>извините, проблема из области психологии - утверждать, что подход в освоении (не изучении, а именно освоении) языка от самого языка не зависит. Если я Вас правильно понял конечно. Поэтому привёл в пример forth , как противоположность к eiffel - это ведь тоже язык с очень интересными идеями, но имеет смысл если программа небольшого объёма и пишет её на 100% один человек и больше никто в его код никогда не полезет. А eiffel на мой взгляд ничего не даёт программисту-одиночке, кроме кучи дополнительных формальностей.Я ваш взгляд понял. Вы считаете, что forth труднее использовать в корпоративных разработках и в крупных проектах (труднее чем в мелких и в одиночку). И вы считаете, что eiffel при разработках "в одиночку" не дает преимуществ.
А мой взгляд по-прежнему, что это вопрос психологический. И пытаясь это отрицать, вы сами при этом переводите разговор на размеры проектов и индивидуальность-коллективность.
А разве вам не известно, что "лезть в чужой код" практически одинаково бывает трудно на любых языках. Для чего по-вашему существуют внутрикорпоративные стандарты.
Eiffel создавался с целью оптимировать работу в больших проектах. А форт создавался с целью достичь наилучший компромис между расходом ресурсов и гибкостью программы на машинке уровня современных микроконтроллеров. И применять языки, и не только для этих два, не по тому назначению для которого их создавали авторы и оттачивало близкое к авторам по целям сообщество - как минимум не рационально. А то можно было сразу отбросить стереотипы и на ассемблере остаться.
>Eiffel создавался с целью оптимировать работу в больших проектах.Eiffel создавался с целью реализации объектно-ориентированной парадигмы и "проектирования по контракту".
Да помнится было время, когда поклонники процедурного программирования утверждали, что не то что какой-то там Eiffel, а вообще ООП имеет смысл применять только в "больших пректах".
>А форт создавался с целью достичь наилучший компромис между расходом ресурсов и гибкостью программы на машинке уровня современных микроконтроллеров.
А форт с успехом применялся не только как средство для достижения каких-то там компромиссов, но и как метаязык - видимо эту важную его особенность вы как раз упустили. А метаязыки как раз и применяются в больших проектах и коллективных разработках.
У вас явно присутствует недостаточная информированность о тех языках, которые вы изучаете.
Знать синтаксис большого числа языков - это еще не означает знать эти языки.>И применять языки, и не только для этих два, не по тому назначению для которого их создавали авторы и оттачивало близкое к авторам по целям сообщество - как минимум не рационально. А то можно было сразу отбросить стереотипы и на ассемблере остаться.
Вам следует внимательнее вдуматься, что такое языки "общего назначения". А также не путать "назначение" языка с поддерживаемыми им парадигмами проектирования.
Так что пока продолжает наблюдаться чисто психологический фактор. А именно - желание убеждать других вместо того, чтобы что-то внедрять самому. "Большие проекты" при этом - плохо осознанное оправдание.
>Делать то, что работает, и осваивать для этого такие инструменты, которые более всего подходят именно вам, а не другим, и которые помогают именно вам самому достичь максимальной производительности.Если Вы имеете ввиду производительность приложений, написанных на Eiffel, то она оценивается как высокая (трансляция кода в Си). А вот производительность самого программиста будет, скорее всего, невысокой. Eiffel прежде всего предназначен для неспешной разработки критически важного ПО. К этому есть все предпосылки: статическая типизация, проектирование по контракту, минимализм самого языка, стремление к математической строгости, отлавливание по возможности как можно большего количества ошибок на этапе компиляции.
>А вот производительность самого программиста
>будет, скорее всего, невысокой. Eiffel прежде всего предназначен для неспешной разработки
>критически важного ПО. К этому есть все предпосылки: статическая типизация, проектирование
>по контракту, минимализм самого языка, стремление к математической строгости, отлавливание по
>возможности как можно большего количества ошибок на этапе компиляции.думаю что в сравнении с C и с учётом отлова типичных для него багов, которых там всё равно не избежать, производительность программиста на айфеле будет всётаки хорошо выше.
>Если Вы имеете ввиду производительность приложений, написанных на Eiffel, то она оценивается как высокая (трансляция кода в Си).Я разве что-то говорил о производительности приложений?
>А вот производительность самого программиста будет, скорее всего, невысокой. Eiffel прежде всего предназначен для неспешной разработки критически важного ПО. К этому есть все предпосылки: статическая типизация, проектирование по контракту, минимализм самого языка, стремление к математической строгости, отлавливание по возможности как можно большего количества ошибок на этапе компиляции.
То есть вы здесь пытались меня убедить, что производительность самого программиста не следует измерять в скорости написания кода и в количестве кода.
Но при этом сами почему-то сделали вывод о низкой производительности программирования на Eiffel.
>То есть вы здесь пытались меня убедить, что производительность самого программиста не
>следует измерять в скорости написания кода и в количестве кода.
>
>Но при этом сами почему-то сделали вывод о низкой производительности программирования на
>Eiffel.
>думаю что в сравнении с C и с учётом отлова типичных для него багов, которых там всё равно не избежать, производительность программиста на айфеле будет всётаки хорошо выше.Смотря с чем сравнивать. Если с C/C++, то возможно Eiffel превзойдет их по скорости работы программиста. А если с сайтами на php, написанными на коленке за пару дней - вряд ли у других языков есть шансы сравняться с php:)
Что касается Eiffel, то его основная цель состоит в том, чтобы программисты сразу писали корректные программы с контрактами, а не сидели часами в отладчике, покрывая свое творение бесчисленным количеством тестов. В общем, сразу все делали правильно, с комментариями и документацией. А это требует времени.
Если Вы хотите попробовать проектирование по контракту, то для других языков есть соответствующие библиотеки. Например, Contract++ (http://dbcpp.sourceforge.net/) для С++. Можете попробовать написать подключаемые модули для php на C++ с помощью этой технологии.
>Если Вы хотите попробовать проектирование по контракту, то для других языков есть
>соответствующие библиотеки. Например, Contract++ (http://dbcpp.sourceforge.net/) для С++. Можете попробовать написать подключаемые
>модули для php на C++ с помощью этой технологии.спасибо, но вот с этого начинать я бы не стал, не опробовав как это в оригинале делается. Тогда такой вопрос: Вы пишите что процесс на TDD похож - а чувствуются ли какие-то преимущества, в сравнении с теми-же UnitTests в стиле явы?
>Вы пишите что процесс на TDD похож - а чувствуются ли какие-то преимущества, в сравнении с теми-же UnitTests в стиле явы?Про TDD - это был не мой пост.
>>Вы пишите что процесс на TDD похож - а чувствуются ли какие-то преимущества, в сравнении с теми-же UnitTests в стиле явы?
>
>Про TDD - это был не мой пост.да, прошу прощения.
Ну наконец-то доделали, прошлой осенью даже помогал Мартину баги из EiffelVision, какой-то заколдованный релиз-стоппер вышел.Сам EiffelStudio, конечно, пока убог, но небезнадежен
>Сам EiffelStudio, конечно, пока убог, но небезнадеженПросто EiffelStudio ориентируется на поддержку возможностей языка Eiffel, а не ставит своей целью создать единую платформу для многих языков типа Netbeans или Eclipse.
> Вышла версия 6.6 IDE для языка EiffelКруто. Слово Eiffel в новости является гиперлинком на вику. А там то по этой ссылке и написано: "В Википедии нет статьи с таким названием."
Epic fail засчитан. Правда не понятно кому. Толи авторам/корректорам новости, толи вике... oO
Прошу прощения, отправил редакторам необходимые изменения.
Вот ссылка на русскоязычную википедию:
http://ru.wikipedia.org/wiki/Eiffel
на англоязычную:
http://en.wikipedia.org/wiki/Eiffel_%28programming_lang...
p.s. Не судите так строго авторов новостей:)