LINUX.ORG.RU

дотнет одноплатформенный по сути, сишарп раздут (слишком много синтаксического сахара, зачем-то сделана возможность написания unmanaged кода)

anonymous
()
Ответ на: комментарий от true

>>По большинству тестов он лучше твоего любимого языка. :)

get the fuckts != true

ЗЫ: Brainfuck наше фсио !

matich ★
()

C# как язык программирования некрасив. Помойка из лишних сущностей. Программерская попса: куча лишних фич, только чтобы казаться круче.

anonymous
()
Ответ на: комментарий от true

> По большинству тестов он лучше твоего любимого языка. :)

лол, пыхпых - не мой любимый язык =) я просто ищу язык для разработки вебсайтов. потому правильнее сравнивать с ASP.NET, которого там и нет ^_^

generatorglukoff ★★
()
Ответ на: комментарий от kto_tama

вот именно это за каким то половым органом там сделали - кури про unmanaged code

anonymous
()

Parrot - наше всьо =) жаль его в тестах нету, интересно, насколько быстрее он выполнит .NET байткод, чем сам .NET ))

kranky ★★★★★
()
Ответ на: комментарий от generatorglukoff

> Прожорство памяти и тормоза на сборщик мусора

Как бы не хотелось в это не верить, но тем не менее NET-овская виртуальная машина жрёт памяти
меньше, чем Java-машина. Да и работают C# приложения побыстрее. 2 главных недостатка же у C# -
он не кроссплатформенный и не бесплатный при том, что мало чем от Java отличается.

Agent666
()
Ответ на: комментарий от Agent666

> Как бы не хотелось в это не верить, но тем не менее NET-овская виртуальная машина жрёт памяти меньше, чем Java-машина.

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

generatorglukoff ★★
()

1. жрёт более ресурсов, раза в полтора-два, по сравнению с .NET 1.0. Например, сравни Студии 2003, 2005.

2. поломали совместимость в платформе, 1.0->2.0->3.5. Хотя местами не сильно, местами серьёзно. То есть смысл его как "кроссплатформенной платформы" не ясен.

3. Язык C# постепенно усложняется и превращается в свалку. То хотели сделать простой язык как Ява, с чуть более удобным синтаксисом, то стали туда добавлять замыкания, лямбды (это ладно, это хорошо) и LINQ, SQL, XML запросы (а это уже свалка).

4. По Mono -- ну наверно самый его большой недостаток что оно вечно будет в позиции догоняющего а .NET сам по себе не шибко стабильный в языке и платформе.

5. ASP.NET с визуальным билдером веб-формочек потенциально приводит к тому, что быдлокодеры, кидающие кнопки на форму в стиле Дельфи продолжают лепить в студии аналогичным образом веб-приложения. Вместо изучения нормального MVC итп.

//чапча guikey

anonymous
()
Ответ на: комментарий от generatorglukoff

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

anonymousI ★
()
Ответ на: комментарий от generatorglukoff

> языки со сборщиками мусора нужны для унылых мозгом

Ты забываешь про огромный фреймворк, который они предоставляют. Писать enterprise, например, на С/С++ бредово.
А по-поводу унылых мозгом: в Lisp тоже сборщик мусора есть, и ты будешь утверждать, что он для унылых мозгом?

Agent666
()
Ответ на: комментарий от generatorglukoff

>языки со сборщиками мусора нужны для унылых мозгом.

Хех, скажи пожалуйста, как реализовать чисто функциональный язык без сборщика мусора? ;)

AiLr ★★
()
Ответ на: комментарий от kto_tama

>отсутствие указателей и адресной арифметики

Указатели есть, но не рекомендуются к использованию. Ну не нужны .NETу указатели. Давайте не смешивать все в кучу. Если нравятся указатели есть C++.

mono ★★★★★
()
Ответ на: комментарий от AiLr

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

Hagalaz
()
Ответ на: комментарий от Hagalaz

Тем не менее в GHC он используется и в обычных функциях (без IO) - как только треть кучи заполнена оно начинает чистить.

AiLr ★★
()

> В реализациях .NET 2.0 и выше от Microsoft и Mono.

неостаток говна в том, что оно воняет (ц)

AiFiLTr0 ★★★★★
()

> .NET

Тормозит хуже жабы.

anonymous
()
Ответ на: комментарий от Hagalaz

> Сборщик мусора в функциональном языке не понадобится, так как у чистых функций нет побочных эффектов, а всё, что происходило во время вызова функции (кроме результата) уничтожится при завешении вызова.

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

Miguel ★★★★★
()
Ответ на: комментарий от anonymous

> ASP.NET с визуальным билдером веб-формочек потенциально приводит к тому, что быдлокодеры, кидающие кнопки на форму в стиле Дельфи продолжают лепить в студии аналогичным образом веб-приложения. Вместо изучения нормального MVC итп.

че прада что-ль ?) это ж просто жжесть ...

phasma ★☆
()
Ответ на: комментарий от Miguel

>Угу, вот в том-то и фишка, что результат может тянуть за собой всё, что было во время вызова функции. Отсюда и необходимость сборщика мусора.

А можно поподробнее, ато я не понял смысл сообщения?

Hagalaz
()
Ответ на: комментарий от Hagalaz

Какое слово непонятно?

Результат может быть сложной структурой, или замыканием, или ещё чем-то там. Соответственно, структура зависимостей между различными частями информации в памяти столь же сложна, как и в ООП-языке. Добавь сюда ещё принципиальную невозможность явно освободить некоторые вещи (например, то, что лежит в замыкании), даже если бы язык поддерживал ручное управление памятью. Итого получаем: функциональный язык без сборки мусора невозможен.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

Ну так а в чём проблема уничтожить всё, кроме того, с чем связан результат, а при уничтожении результата уничтожить всё оставшееся?

Hagalaz
()
Ответ на: комментарий от Hagalaz

То, о чём вы толкуете, молодой человек, известно как "подсчёт ссылок". Это и есть один из методов уборки мусора. Он не так прост, как вам могло показаться на первый взгляд, хотя бы из-за очевидных проблем с циклами. Кроме того, наивный подсчёт ссылок приводит к более низкой производительности по сравнению с современными отслеживающими сборщиками, так что приходится идти на разные ухищрения и оптимизации (что отнюдь не прибавляет коду простоты). А когда дело доходит до многопоточности, то ситуация ещё более того усложняется. Так-то.

anonymous
()
Ответ на: комментарий от Hagalaz

В том, что это "оставшееся" может содержаться где-то ещё, а не только в результате.

Miguel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks