| 1.1, Аноним (-), 14:29, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –22 +/– |
Языки без автоматического управления памятью должны остаться в прошлом веке
| | |
| |
| 2.2, Аноним (-), 14:44, 14/08/2012 [^] [^^] [^^^] [ответить]
| +11 +/– |
Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу. И да, Вы полный неадекват.
| | |
| |
| 3.5, Аноним (-), 14:54, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Пока процессор и остальная обвязка не научится обрабатывать непосредственно высокоуровневые конструкции языков и реализовывать автоматическое управление памятью все уровни программирования от предметно ориентированного до машинного кода будут иметь свою нишу.
А после того, как они это научатся, мы получим аппаратно реализованные тормоза и глюки.
| | |
| |
| 4.6, Аноним (-), 15:01, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Именно так. Хотел дописать, но подумал, что догадаются.
Можно скорректировать:
> ...не научится обрабатывать...
на
> ...не научится эффективно обрабатывать... | | |
| |
| 5.8, Ag (ok), 15:29, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 Эльбрус-1, -2, барроузовские машины - на аппартное управление веделением ОП как то народ не жаловался. Особенно после GETMAIN/FREEMAIN :)
| | |
| |
| 6.9, Аноним (-), 15:37, 14/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и ошибаюсь. В любом случае распространенность остальных систем и распространенность Эльбрус снижают полезность продолжения этой беседы до 0.
| | |
| |
| 7.10, Ag (ok), 15:56, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Не вдаваясь в тонкости управления памятью в Эльбрус-1, -2, изначальный вопрос состоял
> в автоматической сборке мусора, что ИМХО более высокоуровнево, но может и
> ошибаюсь.
Сборка мусора там как раз была. Эльбрусы да, не выжили. А барроузовская платформа вполне себе существует. Только сменила владельца.
> В любом случае распространенность остальных систем и распространенность Эльбрус
> снижают полезность продолжения этой беседы до 0.
Ну почему же. ВМ последние годы активно плодятся. Так что проблема в полный рост.
| | |
| |
| |
| 9.21, Аноним (-), 17:55, 14/08/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Интересно, почему США или там китай не занимаются созданием таких сайтов Может,... текст свёрнут, показать | | |
| |
| 10.31, Аноним (-), 00:21, 15/08/2012 [^] [^^] [^^^] [ответить] | +1 +/– | Как это не занимаются Они просто делают это на гораздо более мощном уровне www ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
| 2.3, Аноним (-), 14:45, 14/08/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами уже сейчас 4х гиг не хватает...
| | |
| |
| 3.12, Vkni (ok), 16:21, 14/08/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
 > Вместе с вменяемыми требованиями к оперативной памяти. Со всякими явами и питонами
> уже сейчас 4х гиг не хватает...
Ну не надо говно брать. Тот же OCaml жрёт очень мало, компилирует значительно быстрее С++, а скорость выполнения примерно такая же.
| | |
| |
| 4.19, Аноним (-), 17:52, 14/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ну не надо гoвно брать.
Кто ж виноват что громче всего орущие скриптокиды обычно про него вещают?
> Тот же OCaml жрёт очень мало, компилирует
> значительно быстрее С++, а скорость выполнения примерно такая же.
Ну и как, рискнули бы вы прокатиться на авто где памятью будет автоматически рулить в критичных системах (отказ которых ведет к ДТП) это нечто? На си можно и полностью статиное распределение памяти отбабахать там где это надо. Так что память ни течь ни кончаться не сможет. А вот на "современных" ЯП - фиг с маслом. Такой уровень предсказуемости и надежности там попросту невозможен как класс.
| | |
| |
| 5.34, Vkni (ok), 01:27, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Ну и как, рискнули бы вы прокатиться на авто где памятью будет
> автоматически рулить в критичных системах (отказ которых ведет к ДТП) это
> нечто?
Эээ, я, знаете, авто никогда не программировал. И большая часть программистов на С - тоже.
Кроме того, на авто, где отказ ПО ведёт к ДТП, я бы предпочёл вообще не ездить. Вне зависимости от того, на чём это ПО написано. (внезапная остановка двигателя к ДТП не приводит)
| | |
| |
| 6.36, Аноним (-), 02:30, 15/08/2012 [^] [^^] [^^^] [ответить] | +/– | А уж жаба-скриптеры и подавно И вот поди ж ты - люди делают вполне себе надежны... большой текст свёрнут, показать | | |
| |
| 7.43, Руслан Зиганшин (ok), 07:21, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > В том числе и с критичными функциями возложенными на софт
Критичные функции _никогда_ нельзя полностью возлагать на софт. За подробностями гуглите Therac-25 (спойлер: медицинский прибор, у которого отключили аппаратную блокировку слишком мощного излучения, что (вместе с кривой прошивкой) привело к смерти нескольких человек)
| | |
| |
| 8.46, arisu (ok), 20:39, 15/08/2012 [^] [^^] [^^^] [ответить] | +/– |  а в железе багов не бывает, ага какая разница, на что там возлагается тестиров... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.4, grondek (ok), 14:46, 14/08/2012 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Пишите аккуратно и не надо автоматически управлять памятью.
А с помощью valgrind'а отладка производится быстро и удобно.
| | |
| |
| 3.7, ВовкаОсиист (ok), 15:14, 14/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Да пускай пишет на говно-языках "будущего". Ему больше ниначём другом писать нельзя. Криворукость головного мозга.
| | |
| 3.11, vkni (?), 16:19, 14/08/2012 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Пишите аккуратно и не надо автоматически управлять памятью.
Это совет никогда не делать ошибок. :-)
| | |
| |
| 4.20, Аноним (-), 17:53, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Это совет никогда не делать ошибок. :-)
На си можно вообще не оперировать выделением памяти. При этом ошибки выделения памяти исключены чисто технически. Если у вас нет malloc то и юзать его вы не сможете. В фирмварях где нужна железобетонная предсказуемость и совершенно неприемлим отказ в невнятных условиях через полгода работы - так и делается.
| | |
| |
| 5.32, pavlinux (ok), 01:10, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > На си можно вообще не оперировать выделением памяти.
Все на константные массивы!!! :)
И кстати, массивы переменной длины уже давно в стандарте.
| | |
| |
| 6.38, Аноним (-), 02:34, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Все на константные массивы!!! :)
В критичных применениях есть и такое. Вплоть до запрета в ответственных применениях адресной арифметики вообще. А как раз чтоб не нарваться на факап лишний раз. Вплоть до того что программа просто не собирается если такое в ней есть.
> И кстати, массивы переменной длины уже давно в стандарте.
Так это... стандарты разные бывают. Под разные нужды. Погугли и подивись: для высоконадежной эмбеддовки от факапа в которой что-то всерьез зависит (типа падения самолета или отвала бошки у опасной промышленной установки) - существует ряд своих требований и стандартов. Некоторые из них налагают по истине драконовские требования. Ради надежности и предсказуемости. Статичное распределение памяти и запрет арифметики с указателями - наиболее очевидное, что первым делом делается.
| | |
|
| 5.33, Vkni (ok), 01:24, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> На си можно вообще не оперировать выделением памяти.
Это вы так тонко советуете вообще программы на С не писать? Разумно, конечно. Всё-таки, глупо писать программы, не выжимающие что-то специфическое из железа, на портабельном ассемблере, когда есть множество других языков.
| | |
| |
| 6.39, Аноним (-), 02:38, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> На си можно вообще не оперировать выделением памяти.
> Это вы так тонко советуете вообще программы на С не писать?
Почему же. На нем вполне можно писать. И даже очень ответственные штуки, которые на чем-то еще пожалуй фиг напишешь так же предсказуемо.
> Разумно, конечно.
Я как бы пытался намекнуть что в сях, стань оно реально надо, можно и вот так. А вот в этих автоматических ж@повытиралках для скрипткидисов - рукоятка отобрана. Система лучше знает. А то что это может к факапу вести и потере предсказуемости - так оно ж для скрипткидей на поиграться.
> Всё-таки, глупо писать программы, не выжимающие что-то специфическое из железа,
> на портабельном ассемблере, когда есть множество других языков.
Ну да, все дураки, пишут уже столько лет системный софт на этом, просто потому что ничего лучше как-то и не появилось. А вот вы тут один умный. Правда на uC давно уже делают довольно критичные штуки, отказ которых вполне может иметь последствия. И программят или на голом асме или на сях. А на чем-то еще как-то и не получается особо, да и предсказуемость совсем не та уже.
| | |
|
|
|
|
| |
| 3.15, VoDA (ok), 16:53, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
 > Расскажи это Apple, пусть заменят ObjC на жабку, сынку
Их Oracle затроллит, так что ObjC так и будут строгать )))
| | |
| 3.17, Аноним (-), 17:41, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
>Расскажи это Apple, пусть заменят ObjC на жабку, сынку
ObjC более продвинутый и современный язык чем Java, к тому же в нём тоже есть автомитическая сборка мусора (опционально)
| | |
|
| 2.18, Аноним (-), 17:48, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Языки без автоматического управления памятью должны остаться в прошлом веке
Довольно лицемерная заява в свете того что недавно был представлен инструмент для борьбы с утечками памяти в ... JS.
p.s. но я искренне желаю вам чтобы у таракашки управляющего "электронным газом" или ABS невовремя кончилась память. Это было бы заслуженным наказанием за общую идиотию и неспособность смотреть вокруг и видеть что-то кроме себя и своих задач.
| | |
| 2.24, Пиу (?), 19:50, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
мнение похаписта очень ценно для нас, пожалуйста продолжайте
| | |
|
| 1.16, ryzhov_al (ok), 17:07, 14/08/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 В OpenWRT и производных появился в нативном виде и прекрасно работает на крохотныъ embedded системах. Трижды рулез!
| | |
| |
| 2.23, Аноним (-), 19:07, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках памяти. Скорее бы ...
| | |
| |
| 3.27, VoDA (ok), 20:01, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Так что можно спокойно писать на машинозависимых языках не задумываясь об утечках
> памяти. Скорее бы ...
А зачем?
Машино-зависимые хороши только когда используемых платформ/железок довольно мало. Как только видов железа становится много, так сразу абстракции/VM/машино-независимость.
PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))
| | |
| |
| 4.28, Аноним (-), 21:10, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> PS C# - машино-зависимый язык. Оно работает только на x86 и x86 64 bit ;)))
И только в виндовсе, по большому счету. Даже кроссплатформенного набора виджетов нету.
| | |
| |
| 5.40, Аноним (-), 02:42, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> http://www.mono-project.com/Supported_Platforms - мужики-то не знали.
Мужики читать не научились. В какоме месте непонимание того что стандартного кроссплатформенного набора виджетов - нет? По поводу чего начинаются извращения, когда вместо paint.net появляется наполовину переписанная pinta. Такой вот хреновый written once, runs everywhere, что даже гтк или куть какой-нибудь более кроссплатформенный. По крайней мере, программы на GTK или Qt не требуется переписывать наполовину при переносе на иную ОС. Как максимум - перекомпилить.
| | |
| |
| 6.41, ... (?), 03:43, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
1. Мой комментарий относился к "x86 и x86 64" предыдущего оратора.
2. Язык программирования никоим образом не связан с "стандартный кроссплатформенный набор виджетов". Gtk# - "стандартный кроссплатформенный набор виджетов" для _платформы_ mono. Windows.Forms - стандартный _не_ кроссплатформенный набор виджетов для _платформы_ .NET.
4. paint.net - столько раз обсуждалось почему так, чтоповоторять это сдесь - просто бессмысленно.
5. Покажите-ка мне программу на Qt или Gtk которая будет кроссплатформенно двигать курсом мыши, работу с окнами (взять дескриптор текущего выделенного окна чужого приложения, у найти у него 3-й дочерний виджет и установить ему какие-либо свойства), установить тему курсоров/окон. Не реализуя нескольких различных вариантов для Windows и Linux. Правда, очень интересно было-бы взглянуть.
| | |
| |
| 7.42, ананим (?), 06:37, 15/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
пятый пункт сразу за слив считать?
или одумаетесь?
зыж
винапи выносит моск напрочь.
не имеет права одна программа менять что-либо в окне другой программы.
точка.
нужно взаимодействие? используйте ipc. дбас наконец (который в кутэ есть).
дескриптор окана? а нету его. в некоторых платформах и окон нету.
курсор? в своём окне хоть сто порций. тема? тоже самое. а в системе - да вы рехнулись.
от подобных манипуляций уже даже мс отказывается (зарывая винапи в вин8рт)
| | |
| |
| 8.45, ... (?), 13:37, 15/08/2012 [^] [^^] [^^^] [ответить] | +/– | Пятый пункт был приведен для того, чтобы показать что утверждение По крайней ме... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.26, VoDA (ok), 19:58, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
Сборка мусора либо автоматическая либо ручная.
То, что приложение можно запустить без VM - ни о чем не говорит. Ту же java можно собирать в нативные бинари. А сборка мусора как была автоматической, так и остается ;)))
| | |
| |
| 3.29, Аноним (-), 21:10, 14/08/2012 [^] [^^] [^^^] [ответить]
| +/– | |
> Сборка мусора либо автоматическая либо ручная.
Вообще, бывали адекватные потуги - разрешить и так и сяк.
| | |
| |
| 4.47, VoDA (ok), 10:05, 24/08/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Сборка мусора либо автоматическая либо ручная.
> Вообще, бывали адекватные потуги - разрешить и так и сяк.
потуги были, а вот результат в мэйнстриме не виден. увы.
| | |
|
|
|
|
