| 1.1, rshadow (ok), 14:32, 22/01/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –10 +/– |
 Мозилла в последнее время выкидывает все что не ФФ и не приносит бабло. Кода мозилла от него откажется?
| | |
| |
| |
| 3.17, Lester (?), 16:03, 22/01/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Возможно будет. Разработчики уже не говорят о ближайшей замене gecko на servo, речь идет о возможном постепенном внедрении частей на rust в gecko. А это, ИМХО, говорит о том, что они хотят зацепиться, чтоб их не забыли и не похоронили, если они не смогут в ближайшее время создать конкурентный аналог. Ну и кроме того, это говорит о том, что они явно недооценили сложность и объем задачи.
| | |
| 3.28, pkdr (ok), 18:05, 22/01/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Вряд ли, учитывая то, что сейчас делают мозилловцы, они проведут статистическое исследование, узнают что на фаерфоксе сидит только треть пользователей браузеров и решат прекратить его пилить вообще, выпустят FireChromium.
| | |
|
| 2.64, D246ner (?), 20:04, 23/01/2016 [^] [^^] [^^^] [ответить]
| +3 +/– |
Если не будет развивать его Mozilla, будут развивать его другие:
В Dropbox пишут новые сервисы на rust, будет кому поддерживать.
Создадут какую-нибудь Nonprofit Organization курирующую разработку, и существующую через взносы, и будут обеспечитвать ЗП разрабочикам языка.
| | |
|
| 1.2, Аноним (-), 14:34, 22/01/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
Некрасивый он и плохо читаемый. Наверно на него пересядут Си-шники.
| | |
| 1.4, index.php (?), 14:47, 22/01/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Когда же наконец запилят один самый мощный язык программирования в котором будет один синтаксис? Сейчас не очень удобно запоминать C++, C#, Python, Ruby, Rust, Go, Swift, Java :'(
| | |
| |
| |
| 3.8, index.php (?), 15:02, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
Нельзя делать сайты и клепать программы под Windows and Android или можно?
| | |
| |
| 4.43, броподрол (?), 22:57, 22/01/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Сайтики уже можно. Windows and Android скоро будет, в баг треке уже баг есть ждите.
| | |
|
|
| |
| |
| |
| 5.20, Crazy Alex (ok), 16:37, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Ну да. Но лисп для мейнстрима банально неудобен. Впрочем, как любое универсальное решение.
| | |
| |
| 6.26, rob pike (?), 17:50, 22/01/2016 [^] [^^] [^^^] [ответить]
| +4 +/– |
И каждый из прочитавших этот комментарий под словом "мейнстрим" понял что-то свое.
| | |
| |
| 7.48, Crazy Alex (ok), 02:06, 23/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
Характеристика мейнстрима только одна - его МНОГО. И это заведомо исключает любой язык, для которого нет орды готовых специалистов и готовых частных решений. Я даже поверю, что на лиспе можно что-то быстро разработать - но на мейнстримных языках, скорее всего, это вообще не придётся разрабатывать - всё давно готово и есть те, кто умеет с этим работать - и в количествах.
| | |
| |
| 8.51, angra (ok), 02:22, 23/01/2016 [^] [^^] [^^^] [ответить] | +1 +/– |  Ну а теперь задумайся, откуда появляются орды готовых специалистов и готовых ча... текст свёрнут, показать | | |
|
|
|
|
| 4.15, freehck (ok), 15:51, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
 Зато на нём можно легко и непринуждённо быстренько зафигачить себе DSL специально под нужную тебе задачу с нужным тебе синтаксисом. :)
| | |
| |
| 5.18, Crazy Alex (ok), 16:25, 22/01/2016 [^] [^^] [^^^] [ответить]
| –4 +/– | |
Можно. Но этот DSL будет весьма слабо читаем.
А вот на любом современном интерпретируемом языке это, скорее всего, будет проще, быстрее и результат будет куда удобнее в использовании. А если взять специализированный язык, которых сейчас хватает для любой области и на любой вкус - результат будет ещё лучше.
| | |
| |
| 6.30, freehck (ok), 19:00, 22/01/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> Можно. Но этот DSL будет весьма слабо читаем.
Это уже зависит от Вас, и только от Вас.
> А вот на любом современном интерпретируемом языке это, скорее всего, будет проще,
> быстрее и результат будет куда удобнее в использовании.
Нет. Просто нет. Без лисповых макросов *проще* и *быстрее* это точно не будет.
Вот давеча понадобился DSL для одной программки на Ocaml, так оказалось проще встроить в него R5RS, чем писать на синтаксический анализатор на нём самом. Но Ocaml, конечно, не "современный интерпретируемый". Однако как написать такое на Perl, Ruby или Lua я даже не представляю.
> А если взять специализированный язык, которых сейчас хватает для любой области и на любой
> вкус - результат будет ещё лучше.
Ну во-первых их вечно НЕ хватает. Во-вторых, как они по-вашему появляются-то?
| | |
| |
| 7.40, QuAzI (ok), 22:02, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
 А сопровождать этот код потом будет полтора магиканца на пенсии? Где-то мы про такое недавно читали =)
FORTRAN учите, будете вообще неувольяемым =)
| | |
| 7.49, Crazy Alex (ok), 02:17, 23/01/2016 [^] [^^] [^^^] [ответить]
| –2 +/– | |
А дайте задачу - уверен, что найдётся пяток готовых решений для чего-то мейнстримного и по столько же модулей на питоне/перле, которые можно по-быстрому прикрутить.
Как появляются - не важно (хотя большинство распространённого написано отнюдь не на лиспе). Важно то, что для абсолютного большинства задач они уже есть, причём в них уже собраны основные грабли и есть союзники в борьбе с оставшимися.
Ну вот есть разница между 80-ми, когда связность была плохой, набор готовых решений - сравнительно малым, сложность задач - терпимой, а набранный индустрией опыт - не таким уж большим, и нынешним временем, когда всё это увеличилось многократно.
Ну не пишет себе сейчас нормальный человек набор контейнеров, виджетов и алгоритмов. Сейчас есть прямой смысл конентрирооваться на одной задаче, а всё остальное брать готовым, и быстро оценить то, что тебе интернетом принесло - гораздо более ценный навык, чем что-то на порядок проще написать самому вне какой-то узкой области. Потому что в первом случае есть шанс хоть что-то за свою жизнь успеть.
Ровно так же, как веке в 17-м можно было заниматься физикой в одиночку и получать хорошие результаты в нескольких областях - а сейчас одиночка не может добиться вообще ничего, и единственный осмысленный вариант - узкая специализация и максимальное использование результатов коллег со всего мира.
| | |
| |
| |
| |
| 10.71, freehck (ok), 15:15, 24/01/2016 [^] [^^] [^^^] [ответить] | +/– | Ну что ж, я могу Вам только посочувствовать, что Вам 100 раз объясняют столь про... большой текст свёрнут, показать | | |
|
|
|
|
| 6.37, . (?), 21:49, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– | |
>А если взять специализированный язык, которых сейчас хватает для любой области и на любой вкус - результат будет ещё лучше.
Ну тЭорЭтически - вот их то лишперы и делают :)
| | |
| 6.62, Онаний Онаниевич (?), 15:41, 23/01/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
Это Вы про JavaScript, Python и PHP чтоли? Более мусорных языков я в жизни не видел (bash не в счёт).
| | |
| |
| 7.69, Crazy Alex (ok), 05:24, 24/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
Из этих - питон как DSL выглядит очень чистенько - определешь нужную библиотеку - и всё. Lua для того же часто используют.
| | |
|
|
|
|
|
| 2.19, iLex (?), 16:29, 22/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Когда-то давно на роль такого языка претендовал C++. Всего каких-то 17 лет назад можно было выучить только его, и получить возможность писать код под любое железо того времени и под любую задачу.
А потом предметная область начала фрагментироваться, причём скорость фрагментирования всё возрастает. Кажется, в мире IT пресловутая сингулярность наступит с года на год, потому как уже сейчас языки, фреймворки и парадигмы плодятся с такой чудовищной скоростью, что даже если начинать учить их сразу после выхода, к моменту изучения они как раз успевают устареть.
Всё идёт к подходу "один проект - один язык", когда количество действующих языков сравняется с числом крупных проектов. И знания, полученные в одном проекте, для любого другого будут полностью бесполезными, т.к. станет практически невозможно найти два проекта, написанных на одном языке.
| | |
| |
| 3.22, Aleksey (??), 16:45, 22/01/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
Это всё hype, его можно спокойно игнорировать, базовые знания по computer science уже годов с 70ых как не устаревают.
| | |
| |
| 4.24, Andrey Mitrofanov (?), 17:30, 22/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Это всё hype, его можно спокойно игнорировать, базовые знания по computer science
> уже годов с 70ых как не устаревают.
Ога, небазовые вперемешку с не-знаниями переполняют аналы.
| | |
| 4.27, rob pike (?), 17:56, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Начните с бенчмаркинга на Haswell классических структур данных и алгоритмов.
| | |
| |
| |
| 6.47, rob pike (?), 01:02, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну, например, можно обнаружить как хитрые списки, над которыми бились лучшие умы в computer science 1970-х, со своими O(1), сливают тупейшим массивам с их позорными O(N) на примерно всех разумных N.
Кнутов с Седжвиками и Корменами формально и не упрекнешь, они скажут что ничего конкретного про сами эти О и не обещали, и вообще это такие математические абстракции, к реальной жизни никак не относящиеся, а что все понаделали себе в головах интуциций про эти O - так это к понаделавшим. Тем не менее, контринтуитивным в реальной жизни для подавляющего большинства овладевших "принципами computer science из 1970-х" оно остается.
А реально влияющие (побольше чем N) вещи типа branch prediction, reference locality, cache awareness в computer science 1970-х описаны, как бы это помягче выразиться, не очень (хотя у IBM был работающий в IBM360 out-of-order еще до 1970-х).
| | |
| |
| 7.50, Crazy Alex (ok), 02:22, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
А детальнее где глянуть? Что-то на практике я об такое не бился, ни на C, ни на плюсах. ни на перле, ни на джаваскрипте. Хотя оптимизировать всякое приходилось.
| | |
| 7.58, Michael Shigorin (ok), 13:43, 23/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
 > Ну, например, можно обнаружить как хитрые списки, над которыми бились лучшие умы
> в computer science 1970-х, со своими O(1), сливают тупейшим массивам с
> их позорными O(N) на примерно всех разумных N.
О как, не слышал.
| | |
|
|
|
| 4.46, й (?), 00:07, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
да-да, особенно представления о многопоточных программах.
| | |
|
| 3.25, Аноним (-), 17:31, 22/01/2016 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> Всего каких-то 17 лет назад можно было выучить только его, и получить возможность писать код под любое железо того времени и под любую задачу.
Сильно подозреваю, что 17 лет назад или ваши задачи были несколько специфичными или же это вообще рассуждения с высоты удобного дивана ) ), типа "главное – возможность! А результат ... ну подумаешь, придется переписать кусок на Си ..."
https://lkml.org/lkml/2004/1/20/20
| | |
| |
| 4.52, Crazy Alex (ok), 02:29, 23/01/2016 [^] [^^] [^^^] [ответить]
| +/– | |
Насчёт c++ exceptions - он, как обычно, ничего не уточнил, так что не понять, насколько он прав.
Уж не знаю, что у него за требования к языку для писания ядра, но вот насчёт "hide things like memory allocations behind your back" - он либо гонит, либо имеет в виду что-то большее, чем аллоцирование в куче.
А вот за "object-oriented code in c without c++ crap" я очень хочу кого-то убить. Эта хрень адски плохо отлаживаается и ещё хуже модифицируется, так как единственный способ сделать ООП на сях (я имею в виду - как положено, с наследованием и полиморфизмом) - куча макросов, от которой тошнит, и не меньшая куча опасных преобразований типов.
| | |
| |
| 5.61, rob pike (?), 15:18, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если бы Линус делал "как положено", у нас бы сейчас вместо ядра были EJB с RMI-IIOP и феминистками.
Так что спасибо ему огромное за то что он руководствуется здравым смыслом и плевать хотел на весь тот crap, который "положен",
| | |
|
|
| 3.32, Michael Shigorin (ok), 21:00, 22/01/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> и под любую задачу
Чё-то не помню я тогда нашествия плюсатых cgi-шек (спрашивали ведь и "за сайты")...
| | |
| |
| 4.45, rob pike (?), 23:30, 22/01/2016 [^] [^^] [^^^] [ответить]
| +2 +/– | |
mod_perl вовремя появился. Сишные модули к апачу писали иногда, если надо было совсем быстро. Но редко, перл не сильно уступал в работе со строками, а ничего другого в вебе было не надо практически никогда.
Хотя базовое утверждение автора, конечно, полная чушь. 17 лет назад на одних FoxPro, Clarion, Paradox и Clipper было понаписано больше кода чем на Си и С++, с большим отрывом.
| | |
|
|
|
| 1.29, Аноним (-), 18:33, 22/01/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Согласно тому что они обещают нет сборщика мусора и нет ручного освобождения памяти. Я правильно понял?
Тогда может ли раст решить задачу и как:
Есть несколько массивов. В начале каждый из них имеет равный размер и содержит указатель(? или как там его называть) на объект. Потом некоторые элементы удаляются. Таким образом на некоторые объекты не остаётся ссылок ни в одном массиве и их надо удалить. Тут если не сборщик мусора, то перед удалением каждого объекта надо просматривать остальные массивы и проверять содержится ли в них указатель и если не содержится то удалять объект. Это единственный вариант который сразу приходит в голову. Но он крайне не эффективен при больших размерах массива и большом количестве массивов.
| | |
| |
| |
| 3.34, Аноним (-), 21:10, 22/01/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Чего первый курс? Вот почему когда задаёшь вопрос, то ответить не могут, упрекнуть в некомпетентности могут, минусовать могут?
| | |
| |
| 4.39, Аноним Аналитег (?), 21:54, 22/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Что ты там написал в первом сообщении вообще не понятно. В основной массе языков без GC используется подсчет ссылок, получаешь ссылку инкрементишь счетчик, как только выходишь из области видимости (scope) происходит декримент счетчика и если он 0 то объект удаляется. Как это работает когда ссылка должна быть передана за scope я не знаю, это все можно нагуглить словами rust memory model scope escape analysis.
У счетчиков есть проблема с циклическими ссылками, когда есть два, три или более объектов ссылающихся друг на друга (A->B->C->A), ничего не знаю про руст, но недавно прочел про swift, в нем можно декларировать слабые ссылки, кейворды я тебе накидал, гугли тему.
| | |
|
|
| 2.35, Анонимус2 (?), 21:40, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
Как раз сборщик мусора решает эту задачу почти как вы описали, т.е. неэффективно. А без сборщика это решается элементарными счетчиками
| | |
| |
| 3.36, Аноним (-), 21:47, 22/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
Есть умный указатель. У него есть указатель и счётчик. Как только мы делаем a = b количество ссылок на a уменьшается, на b растёт. Как только количество ссылок станет равно 0 вызывается деструктор для объекта на который указывает указатель. По сути это и есть сборщик мусора. Который за одно и является счётчиком встречаемости объекта.
| | |
| |
| 4.41, Аноним Аналитег (?), 22:25, 22/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> По сути это и есть сборщик
Если бы это был сборщик мусора... подсчет ссылок использовался для управления памятью в больших приложениях с незапамятных времен. Просто когда у тебя один объект используется в трех разных местах, то без подсчета тяжело понять когда этот объект можно удалять. Но есть там проблемы с циклическими ссылками как я описал выше.
У GC проблема с вынужденными stop-the-world паузами потому никакого real-time на java не пишут и расход памяти. Зато jre решена проблема с фрагментацией памяти и создание нового объекта обходится вроде бы дешевле, за счет того, что памяти у системы ненужно запрашивать, т.к. CG уже запросил с запасом. Хотя и для "С" это не проблема, можно использовать для менеджмента памяти костыли от апача с бассейном и ведрами :)
| | |
| |
| 5.73, freehck (ok), 21:22, 26/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
А как, кстати, производится управление счётчиком "умного указателя" при многопоточной работе? Лочится на время присваивания?
| | |
| |
| 6.74, Аноним Аналитег (?), 23:34, 27/01/2016 [^] [^^] [^^^] [ответить]
| +/– |
У меня нет достаточной компетенции для ответа на вопрос, я джава кодер, максимум доводилось заниматься портированием сишных приложений на джаву.
| | |
|
|
|
|
| 2.56, angra (ok), 06:20, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
Массивы(есть еще tuple и vec) в rust иммутабельны. Так что такая "задача" там просто не возникнет. Также там есть несколько разных типов указателей, есть понятия ownership и lifetime, так что методы работы с ними весьма отличаются от привычных по С.
| | |
| 2.57, Аноним (-), 07:52, 23/01/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
в описанной ситуации rust позволит использовать только указатели с подсчетом ссылок (Rc или Arc). Попытка изменить объект при наличии указателей других типов приведет к ошибке компиляции
| | |
|
| 1.59, 321 (??), 13:47, 23/01/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
>Rust библиотек, которые могут выступать в роли
>прозрачной замены библиотекам для языка Си.
ну, вот и хорошо. перепишите Линукс (ядро) уже на нём.
| | |
| |
| 2.65, Аноним Аналитег (?), 22:30, 23/01/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
+1 Отличная статья. Вопрос можно обобщить s/мнение бывалых C++ ков/мнение бывалых Blub программеров/g :)
| | |
|
|
