LINUX.ORG.RU
ФорумTalks

Сколько ещё будет жить C++?


0

0

С++ был создан довольно давно... но досих пор используется при написании некоторых программ. Как по вашему, как долго он ещё будет жить? Что с ним произойдёт при массовом переходе на не x86 платформы?

anonymous
Ответ на: комментарий от mirage

Ущербное ничтожество, твой lpeg тут вообще не при делах. Pattern matching нужен для структур, идиот, а не для строк.

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

Кретин здесь один - и этот кретин - ты.

Посмотри на pattern matching в ML или Haskell, а потом засунь свой lpeg куда подальше. Ты некомпетентен, необразован и невменяем. Одним словом - ничтожество.

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

> єтот проект зарелизился в єтом году...

Он с нуля был написан?

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

anonymous (*) (14.04.2008 15:09:40) спасибо, а то не знал стоит ли смотреть на этот Lua. а ещё какой нибудь подобный раскритиковать можно?

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

> а ещё какой нибудь подобный раскритиковать можно?

Конечно. Прикол в том, что _так_ "раскритиковать" можно любой язык.

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

Да нет их, подобных. Lua гад такой в геймдеве монополист абсолютный и непревзойдённый. :((((

Тем и раздражает, собственно.

ЗЫ: а уж как он достал в Ion3, это отдельная сказка и песня (со счастливым концом по имени Stumpwm).

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

Проблема Lua в том, что он свою задачу решает плохо. Он применяется в той области, для которой не особо приспособлен.

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

я имел ввиду не геймдев а вообще

tailgunneru против haskela и схемы такая критика непройдёт А где область применения этого lua

zurg
()

:-) При написании "некоторых" программ используется ассемблер, а остальные 99.9999% пишут на си и си++. Поэтому эти языки будут жить еще долго. Да и на замену-то ничего более толкового нет.

Язык платформенно независимый, поэтому ничего с ним не произойдет.

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от zurg

> против haskela и схемы такая критика непройдёт

Точно эти пункты - нет, но настолько же неуместные пртензии можно предъявить и к ним.

> А где область применения этого lua

Встраиваемый скриптовый язык. Но любят его, слава ТНБ, только в геймдеве.

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

> всё, кретин, ты меня утомил. а тебя в ПТУ заждались, тебе ещё двор подметать. иди нахуй.

Какие всё-таки невоспитанные эти регистраты.

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

ничего-ничего, наша сила в нашей невидимости. пока вы «не считаете», мы идём. имя нам — Легион. будет… когда-нибудь… наверное.

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

"Вообще" - так не бывает. Все языки имеют смысл в контексте прикладной области, а не "вообще". Луа как язык описания игровой логики - говно (там вообще декларативный язык должен быть как правило), луа как язык конфигураций - ещё большее говно, кто Ion3 юзал, тот знает. Но я вполне допускаю, что есть прикладные области, где Lua может тихо зарулить. Только я про них ничего не знаю.

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

> остальные 99.9999% пишут на си и си++.

Лживое детко, очень лживое. Мало пороли, явно.

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

4500 огромных человекоподобных боевых роботов, скриптованых на Lua!

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

>язык не такой уж и простой и не такой уж и расширяемый.

программа под названием "схема - язык субстрат" провалилась. Это можно посмотреть в практических реализациях схемы вроде PLT. Там все фичи вроде ООП hardcoded в компилятор.

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

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

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

Академики - те ещё трусы. За что тот же Пол Грэм их и пинает регулярно. Они не то что метапрограммирования без гигиены боятся, они сейчас от языка без жесткой статической типизации шарахаются в ужасе.

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

+1. Cм. ссылку про "Evolution of Haskell Programmer" где они факториал вычисляют 15 разными способами :) и в конце с катаморфизмами -- что академик напишет сам по себе, а что для студентов, чтобы его объяснения поняли :)))

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

>они сейчас от языка без жесткой статической типизации шарахаются в ужасе

и правильно делают. Cтатическая типизация это Ъ. Я бы даже не посмотрел в сторону схемы, если бы разбирался в теории типов достаточно хорошо для написания компиляторов c системами типов второго порядка...

ЗЫ а макросы это та же самая потеря информации для компилятора, кстати.

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

>без жесткой статической типизации

тех академиков что схемы клепают обвинять в этом глупо.

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

Всё хорошо в меру.

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

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

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

>чёрную магию, которую нельзя давать в руки простым смертным.

и языки эти, простым смертным тоже давать нельзя.

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

Почему же? Когда на них навешана статическая типизация, когда макры уже недоступны, то почему нет? Даю их простым смертным, и никто не жалуется. Они даже не знают, что там внутри.

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

>навешана статическая типизация, когда макры уже недоступны

делать это макросами это мега-извращение.

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

Обосновать осилишь? Или более чем на односложные предложения умишки не хватает?

Почему это метапрограммирование - плохая техника реализации языков? Ты самый умный, знаешь, как лучше?

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

>делать это макросами

или препроцессором ( что там ?)

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

>плохая техника реализации языков?

расказ о том какими костылями ты "статическую типизацию" обеспечивал - и будет моим аргументом.

>Ты самый умный, знаешь, как лучше?

конечно, базовый схемо-подобный язык + компилятор с плагинами и подготовленной инфраструктурой.

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

> расказ о том какими костылями ты "статическую типизацию" обеспечивал - и будет моим аргументом.

Никаких костылей. У меня есть реализация Пролога поверх Лиспа (очень много для чего ещё нужно, так что считаем, что есть из коробки), есть язык для работы с AST, есть Pattern matching - то есть, весь джентльменский набор для реализации компиляторов. Этот набор, запрятанный в макру, генерящую код на всё том же Лиспе - и будет той самой мордой статически типизированного языка поверх Лиспа.

> конечно, базовый схемо-подобный язык + компилятор с плагинами и подготовленной инфраструктурой.

Ну и чем тут метапрограммирование помешало? Как раз с ним это делается проще всего - компилятор становится частью языка.

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

>и будет той самой мордой статически типизированного языка поверх Лиспа.

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

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

Тривиально. На входе - AST языка без типов (или с аннотациями), у макры есть доступ к environment, где вся информация о типах есть.

Далее AST преобразуется так, что каждому выражению, которое может иметь тип, приписывается id (грубо говоря - типовая переменная), затем для всех пар id-выражение составляются уравнения по очень простой схеме. Система уравнений решается встроенным Прологом, так что никаких хитростей тут не нужно. То место, где Пролог загнулся, высвечиваем как ошибку, если не загнулся - заменяем все переменные, относительно которых система решена, на конкретные типы. Всё, типизированный AST готов, можно компилировать дальше. Задача отработанная до автоматизма и весьма тривиальная.

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

ну и какие плюсы здесь дают именно макры ? такое количество работы с AST делает это практически компилятором... причем не очень эффективным... потому что внедрение оптимизатора, для которого нужно промежуточное представление, сделает это ещё более компилятором... чего конечно допустить нельзя ! потому что макры !

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

Почему это допустить нельзя? Чем это макры несовместимы с компиляцией? Метапрограммирование на макрах позволяет настраивать один такой язык над другим, естественным путём, с максимально возможным code reuse, тогда как классический компилятор, не имеющий доступа к рантайму целевого языка, сделать не в пример сложнее.

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

ладно анонимус, может ты и прав, но я приличных компиляторов на макрах не видел (ссылки ?) по мне, транслятор (c стандартыми либами для лексера/парсера/итп) написать проще... и лисп - далеко не идеальный бекэнд язык... си или ллвм лучше, больше свободы.

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

Я видел как минимум одну такую систему.

Там правда Лисп специфичный - с goto, с ассемблерными вставками, и ты ды. Как раз как низкоуровневый бэкенд самое то, если бы не .net. Ищу теперь хоть немного портабельный способ делать ассемблерные вставки в Common Lisp.

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

> Ищу теперь хоть немного портабельный способ делать ассемблерные вставки в Common Lisp.

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

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