GoingNative-2012

Всичко за програмирането на игри - архитектура, графика, звук, изкуствен интелект, мрежи.
gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

GoingNative-2012

Мнение от gemicha » 04 фев 2012 21:24

Много добри презентации от едни от най-важните в софтуерната индустрия хора:

http://channel9.msdn.com/Events/GoingNa ... ative-2012

Потребителски аватар
KosSiO
Power User
Power User
Мнения: 316
Регистриран: 20 окт 2008 19:29
Местоположение: Targovishte,Sofia

Re: GoingNative-2012

Мнение от KosSiO » 05 фев 2012 18:53

От това, което прегледах виждам, че доста голям акцент се поставя на STL

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: GoingNative-2012

Мнение от pdimov » 06 фев 2012 18:45

"Now, you might say, well, you broke some code, then you fixed it, way to go, committee." - ST "Dread Pirate" Lavavej :-)

ikolev
модератор
модератор
Мнения: 1657
Регистриран: 20 ное 2003 22:39
Местоположение: София
Контакти:

Re: GoingNative-2012

Мнение от ikolev » 22 фев 2012 00:53

Мда, доста интересно нещо за гледане. С жертви успявам да вмъкна по половин-един час на ден в програмата си. Стигнах до Хърб. Според мен най-сериозния проблем на С++ не беше сред изброените. За мен това е трудното създаване на CASE средства, заради трудното компилиране и автоматична обработка на кода. Езикът за програмиране (с компилатора си) отдавна не е единственото средство за производство на софтуер. (Малък пресен пример от ежедневието - coverage библиотеки за С++ има само няколко, скъпи, и една безплатна която май хич не е лесна за ползване.)
Все пак, С++11 вдъхва надежди. И все пак аз продължавам да чакам някой да се захване с D в по-голям мащаб...

ikolev
модератор
модератор
Мнения: 1657
Регистриран: 20 ное 2003 22:39
Местоположение: София
Контакти:

Re: GoingNative-2012

Мнение от ikolev » 26 фев 2012 23:38

Ха, алилуя! Точно в следващата лекция засегнаха проблема със средствата. Бях чувал преди време за Clang, не му обърнах внимание тогава, явно е стигнал далеч. А най-впечатляващото за мен беше в последните 10 минути на всичките тези над 11 часа, когато Чандлър каза какви средства за автоматична обработка на кода са направили. Ами чакаме да ги пуснат, и се надяваме да станат малко по-достъпни за Windows.
И все пак... колкото и да поддържаш стария код и старите програмисти, те все в един момент ще си заминат. А нови проекти започват постоянно, и не виждам защо един нов проект да не избере изцяло нов език базиран на С++, с премахнати всички остарели елементи, с приложени знанията натрупани за над 20 години опит... какъвто всъщност може да стане D.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: GoingNative-2012

Мнение от pdimov » 27 фев 2012 04:28

Кои остарели елементи смяташ да премахнеш от C++?

Потребителски аватар
themean
Power User
Power User
Мнения: 860
Регистриран: 02 дек 2010 22:51

Re: GoingNative-2012

Мнение от themean » 27 фев 2012 10:45

Защо трябва да се махат някви неща :)
Нали не пречат

aSmith
Regular User
Regular User
Мнения: 80
Регистриран: 11 авг 2004 20:09
Местоположение: София

Re: GoingNative-2012

Мнение от aSmith » 28 фев 2012 01:16

pdimov написа:Кои остарели елементи смяташ да премахнеш от C++?
#include например :) (не баш да се премахне, но да се добавят плануваните import/модули).

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: GoingNative-2012

Мнение от pdimov » 28 фев 2012 07:05

Модулите са чудесни, спор няма, но освен ако и C не ги придобие някак си внезапно, трудно ще се освободим от #include.

Потребителски аватар
stoiko
Power User
Power User
Мнения: 617
Регистриран: 04 дек 2003 15:44
Контакти:

Re: GoingNative-2012

Мнение от stoiko » 28 фев 2012 11:58

в D има модули :). защо не оставите C++ да умре и не минете на друг език който не е обременен от тежко детство?

aSmith
Regular User
Regular User
Мнения: 80
Регистриран: 11 авг 2004 20:09
Местоположение: София

Re: GoingNative-2012

Мнение от aSmith » 28 фев 2012 12:21

Защото в света е пълно с pure-c библиотеки и Д-то не ги поддържа native-но. Не знам дали си си играл да подкараш някоя библиотека, ама хич не е забавно.
Освен това концепцията за namespace-и в Д е много зле - всеки файл/модул дефинира негов си namespace и ако не искаш да пишеш по 10к реда във файл става мазало. (това беше в 1.0.хх, не знам дали в 2.хх са го оправили).
Пък и Д е скучен език и изключително лице-приятен (като няма указатели и кода изглежда по-чистичък и лесно-четим), което сваля нивото на coolness и geekness :)

И да не съм напълно off: Лекцията на Александреску за variadic templates, ако не друго поне беше забавна :)

ikolev
модератор
модератор
Мнения: 1657
Регистриран: 20 ное 2003 22:39
Местоположение: София
Контакти:

Re: GoingNative-2012

Мнение от ikolev » 29 фев 2012 00:41

pdimov написа:Кои остарели елементи смяташ да премахнеш от C++?
?!
Мислех че има куп очевидни.
Хайде да кажем така - език, чиито гурута се поправят един друг на конференция пред сума народ по основополагащия въпрос как е най-добре да се декларира даден параметър на функция, явно... ами меко казано има проблеми.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: GoingNative-2012

Мнение от pdimov » 29 фев 2012 04:07

ikolev написа:
pdimov написа:Кои остарели елементи смяташ да премахнеш от C++?
?!
Мислех че има куп очевидни.
Не би следвало да ти е проблем да изброиш десетина тогава. :-)
ikolev написа:Хайде да кажем така - език, чиито гурута се поправят един друг на конференция пред сума народ по основополагащия въпрос как е най-добре да се декларира даден параметър на функция, явно... ами меко казано има проблеми.
Това в коя сказка е и на коя минута горе-долу? :-) Видях Хърб, че на слайд номер N казва "никога не подавайте shared_ptr по стойност", след което на слайд N+2 дава пример, който не работи, но се оправя точно с подаване по стойност, обаче не забелязах някой да го поправи. В случая различните подавания правят различни неща, и едното е правилно, а другото не. В други случаи обаче е обратно. Така че, ако смяташ примерно да премахваш подаванията по стойност, това няма да ти реши проблемите, а ще ти създаде нови.

ikolev
модератор
модератор
Мнения: 1657
Регистриран: 20 ное 2003 22:39
Местоположение: София
Контакти:

Re: GoingNative-2012

Мнение от ikolev » 29 фев 2012 23:38

pdimov написа:
ikolev написа:?!
Мислех че има куп очевидни.
Не би следвало да ти е проблем да изброиш десетина тогава. :-)
Вероятно очакваш да изброя някакви принципни проблеми (не че няма и такива, като споменатите #include-и, из нета е пълно с тях, нямам време да им правя резюме). Аз имах предвид елементарни неща които спъват студентите и начинаещите програмисти. Например, само наличието на четирите оператора . * -> & вече е проблем дори за опитни (2-3 години опит със С#) програмисти. В С# има само оператор точка. Трябва да видиш какво става когато студенти и начинаещи програмисти пишат С++ код в продължение на година. Ако тръгнеш да ги контролираш за всяка буква, ще трябва цялата въпросна година само да се учат без да завършат проект. В повечето фирми това не се допуска. Иначе същите програмисти се справят прилично на С#, особено като им наложиш някое автоматично инструментче за контрол на стила.
pdimov написа:
ikolev написа:Хайде да кажем така - език, чиито гурута се поправят един друг на конференция пред сума народ по основополагащия въпрос как е най-добре да се декларира даден параметър на функция, явно... ами меко казано има проблеми.
Това в коя сказка е и на коя минута горе-долу? :-) Видях Хърб, че на слайд номер N казва "никога не подавайте shared_ptr по стойност", след което на слайд N+2 дава пример, който не работи, но се оправя точно с подаване по стойност, обаче не забелязах някой да го поправи. В случая различните подавания правят различни неща, и едното е правилно, а другото не. В други случаи обаче е обратно. Така че, ако смяташ примерно да премахваш подаванията по стойност, това няма да ти реши проблемите, а ще ти създаде нови.
Да, Хърб каза че shared_ptr трябвало абсолютно винаги да се подава по const&, и мисля че в последната говорилня Стефан го поправи - когато искаш да правиш копие на нещо (каквото и да е), подавай го по стойност, ако само ще го гледаш - по const&. На това място Андрей добави че това винаги е било така в С++. Прав е, но щом Хърб може да се обърка, нали се сещаш какво става с въпросните не-гуру програмисти, на които си им направил и табличка кога как трябва да се декларират параметрите на функции? Те пак си подават просто string, защото във всички по-човешки езици е така. И като няма автоматичен инструмент който да ги поправи, се оказва че шефа им трябва постоянно да ходи подир тях, в следствие на което няма свършена работа.
Да, някои се научават след година-две практика, но само ако по някаква вътрешна причина С++ "много ги кефи". И пак не е трудно да сбъркаш, дори да си спец, защото такива правила "как да се направи нещо правилно" има много.
В това отношение Чандлър с неговите милион маймуни е на прав път. Един ден може би компилаторите ще имат опция с която ще позволяват само "правилен" С++, а интелисенса, автоматичното форматиране и куп други инструменти ще работят безотказно. Тогава ще остане само по-бавното изучаване на езика заради особеностите на синтаксиса му (като въпросните . -> * &).

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: GoingNative-2012

Мнение от pdimov » 01 мар 2012 02:06

Когато се създава език за програмиране, винаги се налага да се фокусираш върху определен тип аудитория. По-широката достъпност обикновено е в разрез с други неща, като повече контрол и повече мощ. C++ е елитен език. Програмисти с 2-3 години опит, чийто мисловен модел за машината не им позволява сравнително бързо да схванат кога кое от & * . -> да ползват, теоретично може и да са елитни програмисти във всяко друго отношение, но на практика вероятността за това е малка.

gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

Re: GoingNative-2012

Мнение от gemicha » 01 мар 2012 08:45

pdimov написа:C++ е елитен език.
Търсих някъде "+1" или "Like" ама в този форум няма :)

Според мен C++ се цели в топ 20% от програмистите. C# се цели в топ 80% от програмистите. От там идват някой разлики.

Отговори