Вышел MonoDevelop 1.0 Beta 1

> Дай угадаю: Хаскель?

Не угадал. Ближе к энтерпрайзу бери.

Also, дай угадаю: ты в жизни на нем ничего не писал, и если и видел, то только на картинках и издали?

Сложность языка меряется не кол-вом ключевых слов (тогда Brainfuck - самый простой), а простотой его использования. По сравнению с Ссы с крестами и Жабой - C# - проще.

Самый сложный по грамматике и кол-ву ключевых слов - Pascal. Но Делфинисты считают, что их язык проще, чем Ссы с крестами.

Так что учи матчасть.

>>программа нужна, чтоб программист бабла поднял и не перенапрягся, бедный

>Добро пожаловать в реальность. Хотя, обычно, бабло поднимают не программисты, а их работодатели. Один хрен. Разве это плохо -- поднимать бабло?

Да нет, неплохо. Но какой-то баланс интересов должен быть... А то будут сплошные ЕГАИСы получаться.

> Also, дай угадаю: ты в жизни на нем ничего не писал, и если и видел, то только на картинках и издали?

Я то с явой хоть угадал?

> Сложность языка меряется не кол-вом ключевых слов (тогда Brainfuck - самый простой), а простотой его использования.

И где тут C# - прост? на нем только в 3.0 разрешили не писать имена типов локальных переменных, если они и так очевидны.

> По сравнению с Ссы с крестами и Жабой - C# - проще.

О, да.

> Если имелась в виду не Ява, то я упаду в обморок....

Не надо падать. Она.

> А зря. 30 лет назад мышки и окошечки уже были, думаешь через 30 лет все радикально поменяют? :)

Могут, на самом деле. Вон, с 3D экспериментируют же — и кто знает, вдруг среди кучи поделок чего и вылезет хорошее. Да и на WIMP все же поддавливают те же tiled WM'ы...

> Самый сложный по грамматике и кол-ву ключевых слов - Pascal.

Ты глубоко ошибаешься. Там нет к примеру yield. И анонимных функций. И вообще там ничего нет.

> Но Делфинисты считают, что их язык проще, чем Ссы с крестами.

Они глубоко ошибаются. Там generic containers нет (как идеи), и шаблонов нет. Не упоминая встроенные списки и хеши всяких питонов. Паскаль - самый сложный в использовании язык. Я на нем в силу ошибок молодости достаточно написал, увы.

> Сложность языка меряется не кол-вом ключевых слов (тогда Brainfuck - самый простой), а простотой его использования.

Дык, еще Профессор, ведь, говорил что различия в синтаксисе — для [далее нецензурно], и смотреть надо только на семантики.

> Могут, на самом деле. Вон, с 3D экспериментируют же — и кто знает,

Человечество несколько *тысяч* лет смотрит на *плоские* устройства изображения информации. 3Д осмысленно при наличии 3Д "мониторов". Но глазу придется фокусироваться дальше-ближе, и чувствовать себя он будет хуже

>Не угадал. Ближе к энтерпрайзу бери.

В энтерпрайзе нынче в моде Java да C#. На C# отстрелить себе ногу определённо проще, чем на Java. Значит, не он. Java? Так бы и подумал, но, по сравнению с Хаскелем, Ява предоставляет просто уйму возможностей накосячить. Приведение чего угодно к типу Object и обратно, неинициализированные (null) объекты.. Сегфолта не будет, но неперехваченное исключение немногим лучше.

> Память у#бища жрут? Жрут. Тормозят? Тормозят. В топку.

Память жрут кривые программы на С и Дельфи. И сегфолтятся.

Возможно Вы правы. Давайте не будем с этим оффтопиком разбираться и гадать на кофейных гущах, а доживем и посмотрим что там будет.

> ак бы и подумал, но, по сравнению с Хаскелем, Ява предоставляет просто уйму возможностей накосячить.

Косяки, они не только в нулевых ссылках. Тупой синтаксис явы предполагает исключить семантические косяки в коде. Тут ява явный чемпион.

>> Память у#бища жрут? Жрут. Тормозят? Тормозят. В топку.

> Память жрут кривые программы на С и Дельфи. И сегфолтятся.

в том-то и дело, что даже НЕ кривые программы на у#бищах жрут память и тормозят.

> в том-то и дело, что даже НЕ кривые программы на у#бищах жрут память и тормозят.

Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

> Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

например для каких? вспоминается только программа для tommy :)

> Приведение чего угодно к типу Object и обратно

В Хаскеле тоже достаточно небезопасных вещей. Посмотрите на слова «unsafe», то же unsafePerformIO, Unsafe.Coerce и т.д., например. Так что руки никак не связаны, все дано, и если хочешь и уверен, что не попадешь в ногу — стреляй.

А вот тот же карринг на жабе это дикий энтерпрайз: http://dis.4chan.org/read/prog/1180896798/

>Ты глубоко ошибаешься.

Это ты глубоко ошибаешься. Ты ни черта не понимаешь в компиляторах и языках. Учить матчасть.

>> Ты глубоко ошибаешься.

> Это ты глубоко ошибаешься. Ты ни черта не понимаешь в компиляторах и языках. Учить матчасть.

анонимус нас научит

> > Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

> например для каких? вспоминается только программа для tommy :)

Для любых, когда пользователь скорее будет рад потратить требуемую суммы денег на железо, чем увидеть непредсказуемый сегфолт ;)

>Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

А теперь по-русски :)

> А вот тот же карринг на жабе это дикий энтерпрайз: http://dis.4chan.org/read/prog/1180896798/

Я вот думаю, не дать ли лабы на J2EE. Задание - раздуть задачу типа факториала на 1000 строк минимум (считая META-INF и прочая).

Ну и че ты сморозил. Пожирание происходит при создании объектов. Что такое недетерминированное создание объектов? Детерминированное удаление объекта это зло. Если мы используем стандартный диспетчер памяти - это тормоза в критические моменты. В нормальных системах с диспетчерами памяти на С++, объекты не сразу удаляются из памяти. Там удаляются целые блоки, причем в недетерминированные моменты времени. Ты, я вижу, диспетчеры памяти не писал, а чего тут ахинею несешь какую-то.

Знакомые с 10-ым правилом Гриспуна студенты напишут на Java встроенный интерпретатор Лисп, и решат задачу на правильном языке :) Как раз что-то типа 1000 строк в сумме.

(Впрочем, есть инверсия этого правила: "Any sufficiently complicated Common Lisp or Scheme program will eventually be rewritten in C++, Java, or Python.")

Лучше бы улучшили (усложнили) объектную модель этого линюхового недо-NET...

> Я вот думаю, не дать ли лабы на J2EE. Задание - раздуть задачу типа факториала на 1000 строк минимум (считая META-INF и прочая).

Кафедра изучения индийской культуры и народных промыслов, специальность энтерпрайз-кодер?

>>> Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

>> например для каких? вспоминается только программа для tommy :)

> Для любых, когда пользователь скорее будет рад потратить требуемую суммы денег на железо, чем увидеть непредсказуемый сегфолт ;)

пардон, а чем отличается непредсказуемый exception от непредсказуемого segfault?

> Что такое недетерминированное создание объектов?

У меня был недетерминированный жор памяти - когда она не очищается в силу кривости рук программиста. У вас Xorg никогда 600Мб не кушал что ли? :)

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

Я учебные диспетчеры памяти писал. Однако речь не о них, а о банальных вещах типа "через час работы /игрушка/бета Xorg/whatever/ начинает жрать 2Г памяти"

> Я вот думаю, не дать ли лабы на J2EE. Задание - раздуть задачу типа факториала на 1000 строк минимум (считая META-INF и прочая).

> Кафедра изучения индийской культуры и народных промыслов, специальность энтерпрайз-кодер?

Я еще не определился. Первая лаба в курсе на ерланге (и интерфейсом на любых рельсоподобных), думаю теперь пора с обратной сороны рассмотреть вопрос - "чем больше кода, тем лучше" :).

> Знакомые с 10-ым правилом Гриспуна студенты напишут на Java встроенный интерпретатор Лисп, и решат задачу на правильном языке :)

Это будет два, им же будет поставлена прямо противоположная задача...

>> Детерминированое поедание и торможение для многих приложений лучше недетерминированного.

> А теперь по-русски :)

В падучие игры, жрущие 2Гига на второй час использования, ни разу не играли?

>пардон, а чем отличается непредсказуемый exception от непредсказуемого segfault?

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

> Меня всегда забавляют Java/NET быдлокодеры. Если у них отнять IDE они сразу впадают в панику и слезы. Тьфу.

а если у тебя отнять гцц с ви - то что делать будешь? руками на бумажке компилЯть?

> Я даже боюсь загадывать что будут собой являть интерфейсы в 2030.

Вы пересмотрели фильмов про будущее? :) Ничего кардинально через 22 года не изменится в области интерфейсов. Ну если конечно не научатся читать мысли...

зачем он нужен?

> а если у тебя отнять гцц с ви - то что делать будешь? руками на бумажке компилЯть?

Нет, без проблем пересяду на другой компилятор и текстовый редактор, базовые принципы работы я ведь знаю, и мне не важно какого цвета и где расположена кнопочка `Скомпилировать поделку'.

> > Меня всегда забавляют Java/NET быдлокодеры. Если у них отнять IDE они сразу впадают в панику и слезы. Тьфу.

> а если у тебя отнять гцц с ви - то что делать будешь? руками на бумажке компилЯть?

Сравнение некорректное, у них ведь не отняли javac/csc/Scite ;)

>> пардон, а чем отличается непредсказуемый exception от непредсказуемого segfault?

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

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

да, кстати, оракл вроде не на жабке написан, так что не все боятся писать на языке с сегфолтами :)

Ты быдло. ГЦЦ-шники ваще ламерье. Настоящие пацаны не доверяют ни компиляторам, ни интерпретаторам, ни JIT-ам. Они пишут руками исполнимый файл.

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

Ага, при сегфолте транзакция в БД отменяется, а уже вылезшие из банкомата деньги залезают в него быстренько назад! Бу-га-га. Не выйдет - процедура выдача денег не обладает свойствами транзакционности!

>а там на случай краха клиентской части существуют транзакции.

Так в том-то и засада, что данные могут попортиться без всякого сегфолта, тихо и мирно. Потом уйдут с очередной транзакцией в базу данных. И только совсем потом, спустя пару часов, программа засегфолтится :)

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

> Ага, при сегфолте транзакция в БД отменяется, а уже вылезшие из банкомата деньги залезают в него быстренько назад! Бу-га-га. Не выйдет - процедура выдача денег не обладает свойствами транзакционности!

деньги вылезают по завершению транзакции, не замечали?

> Так в том-то и засада, что данные могут попортиться без всякого сегфолта, тихо и мирно. Потом уйдут с очередной транзакцией в базу данных. И только совсем потом, спустя пару часов, программа засегфолтится :)

ну а нефиг нанимать быдлокодеров :)

> деньги вылезают по завершению транзакции, не замечали?

Да, сегфолт будет как раз между строчкой commit и перед выдачей. Злые клиенты ломают бедный банкомат ;)

> ну а нефиг нанимать быдлокодеров :)

А не лучше воспользоваться *адекватным* инструментом?

>> деньги вылезают по завершению транзакции, не замечали?

> Да, сегфолт будет как раз между строчкой commit и перед выдачей. Злые клиенты ломают бедный банкомат ;)

Вы никогда не пользовались банкоматами "сбербанка"? Там такое сплошь я рядом: и невыданные деньги, и бсоды, и посторонние окошки от винды поверх главного интерфейса....

>> ну а нефиг нанимать быдлокодеров :)

> А не лучше воспользоваться *адекватным* инструментом?

да. и это обязательно должен быть язык с автоматическим управлением памятью? а зачем?

Mono не нужен.

> да. и это обязательно должен быть язык с автоматическим управлением памятью? а зачем?

Потому что ставить бизнес в зависимость от криворукости программиста - глупо. С точки зрения бизнеса.

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

ну вот привет о чем и речь :)