Какой язык программирования наиболее перспективный?

Здравствуйте,всем попавшим в нежные ,теплые,заботливые руки интегрированных систем,оболочек,
продуктов,студий,платформ.Под их усыпляющий шелест,вы уснули,и может быть надолго.
Спать будете долго,может быть до конца профессиональной карьеры и видеть сон:
- не надо ничего оптимизмровать
- ничего нестандартного подключать не надо
- не надо ничего защищать,есть антивирусы
- в чужой код лезть не надо,даже если ты лопается от любобпытства
- стоит ящик и работает,чего еще надо
Но вот приходится наконец просыпаться,когда осознаешь,что нужно посмотреть в ящик,определить,что работаешь с конкретным микропроцессором,конкретной системой и на конкретном интерфейсе,которые требуют вмешательства из вне в силу своих достоинств и недостатков.
Нужно проснуться и потому,что завтра экран может стать сплошным настолько,что ты не нужен будешь как проффи,а пока вы танцуете на разных платформах под заказ и при этом недозволено повторяться .Вас втянули танцевать,обнажаясь на моря и океаны,от москвы до вашингтона,
на мировой сцене бесплатно,не давая осознать что СОС это ОС,экранирующая низко-уровневые
програмно-аппаратные средства сети по обслуживанию запросов.
Языки програмированичя,сегодня это скорее всего технология ,метод,который используется для решения конкретной задачи,не требующий глубокого изучения,а используемый как справочный материал,но технология требует знать возможности и технические характеристики.
Это таинство его использующего,скрытого от посторонних глаз и главное в нем -это метод,алгоритм,
которые не требуют интерпретации как язык программирования.
Просыпайтесь,господа,идите в начало и вы сами будете создовать интерфейсы,платформы такие,
которые будут удовлетворять требованиям ваших заказчиков.Создовайте сами СУБД,не забывайте,что их делали такие же как вы,но ваши будут болеее защищены и менее ресурсозависимы.Не ройтесь в ГУГЛЯХ,там есть то,что вы сами туда заносите,помимо средств разработчиков,не забывайте о том,что один и тот же продукт часто в инете выставляется под 150
разных имен.Пишите код НТМL от начала и до конца сами,не забывая в некоторых местах конкретно
поинтересоваться внутренним содержимым на низком уровне.
Разработав програмный модуль или пакет модулей в той или иной экранной студии в силу ограничения по времени,постарайтесь собрать свой модуль или пакет без студии,сделав его независимым от нее.Работая с платформами,не забывайте,что это расширения пользовательского
интерфейса,сделанного на основе обновлений,добавлений функций ,которые вам так хорошо
известны и вызванных некоторой конкретной особенностью аппаратных средств или потребностями
пользователя.
И наконец,самое главное:
УЧИМСЯ ПРОГРАМИРОВАТЬ НА АССЕМБЛЕРЕ.
дададада, назад к пещерной графике и палке-копалке.
и нахуя нужны были годы развития ИТ?

либо аффтор - фанатик и настрочил это на самостоятельно написанной с нуля и на ассемблере операционной системе,
либо он очередной балабол.
в любом случае КГ/АМ.
 
против асемдлера ничего лично не имею, самый мощный язык из всех которых видел
 
Oracle -) если оч хорошо шарить мона ехать за бугор и быть модным челом-)

А если спуститься на землю то .NET или Java.
 
C/C++ был, есть и будет... почему? да потому что это и есть то самое отличное соотношение гибкость/производительность/относительная простота
да и как говорилось ранее, с С++ можно перейти на все другие..

а специалисты по ассемблеру всегда быдут не лишнеми!
 
тот, в котором вы профи
 
И наконец,самое главное:
УЧИМСЯ ПРОГРАМИРОВАТЬ НА АССЕМБЛЕРЕ.

Нихуя, это тоже слишком высокоуровнево - писать на ассемблере в винде, написанной на C++ и в ноутпаде написанном на нем же.
Иди дырявь перфокарты дыроколом.
 
Эх, где бы только джуниором на C++ устроиться... хоть за еду/проезд, а то перейти то с него можно на C# или Java можно, только куда ни глянь - кроме самих плюсов еще кучу всего знать надо.
 
только куда ни глянь - кроме самих плюсов еще кучу всего знать надо.
не ведись, никто этой кучи гамна не знает,
ибо не поместится в голове даже у слона.
подразумевается наличие общих представлений
и умение быстро научиться любой фишке из заявленной кучи.

работать за еду можно на любом фрилансерском сайте.
даже ездить никуда не надо.
 
Это ты про какой C++ сейчас говорил? Тот, который под VS нативный, или тот, который под CLR?

я вообще про стандартный с++... но к сожелению, таковых компилятороов нет, все не без изьяна... хотя и в разных степенях:(

лично я отношусь негативно к VS, а к CLR так тем более...
а вообще GCC рулит :клас: хотя я лучше всего знаю билдер) судьба, блин... вот хочу перейти на VS.
 
Наиболее перспективно то во что вкидывают денежку и то что лучше всего подходит для конкретной задачи или области. Данный вопрос провоцирует достаточно большое количество холиваров.

А и еще. Там много про асм говорят, так вот - чтобы что-то говорить об этом, как минимум нужно соску со рта вытянуть.
 
Не главное изучать какую-то современную технологию, которая якобы приносит больше денег, главное быть специалистом в своей области. Для примера:
.NET, C++ , Java.
У всех трёх средняя зарплата около 1000 у.е., специалист высокого уровня получает до 3к, вне зависимости от того пишет он на С#, Яве или плюсах.

Лично я изучаю .NET. Не вижу перспектив у неуправляемых языков а.к.а. С++. Хотя и Java тоже рулит: спрос довольно велик и ЗП на уровне.
"Неуправляемый" - это каг? С опасными указателями, "сырой", что ли??? Ну так я смотрю, что люди уже забывать начали о том, что родоначальник PHP, Java, .NET и всех остальных - это как раз тот самый "неуправляемый" C++. Кстати, по возможностям, предоставляемым для работы близко к аппаратному уровню всегда будет использоваться С++.
 
Кстати, по возможностям, предоставляемым для работы близко к аппаратному уровню всегда будет использоваться С++.

А JVM или CLR не позволяют получить необходимый доступ? Скорость разработки побыстрее будет, да и такие прелести как сборщик мусора достаточно приятны. Чтобы писать на С++ качественные приложения нужно опыта и знаний побольше. Одним плюсом является отсутствие среди Сшников школьников(если хотите возразить - подумайте, можно ли вас назвать Сшником). Для разработки десктоп приложений С++ не пригоден, для веб тоже. Почему? Потому что затраты больше чем альтернатива(Python Senior стоит дешевше баксов на 500-1000 чем С++), а прибыль та же.
 
Турбо Паскаль 7.0 - самый преспективный!
 
"Неуправляемый" - это каг? С опасными указателями, "сырой", что ли??? Ну так я смотрю, что люди уже забывать начали о том, что родоначальник PHP, Java, .NET и всех остальных - это как раз тот самый "неуправляемый" C++. Кстати, по возможностям, предоставляемым для работы близко к аппаратному уровню всегда будет использоваться С++.
Если ты не знаешь в чём отличие управляемого от неуправляемого, то даже не знаю... наверное ничем не могу помочь тебе..)
 
Эх, где бы только джуниором на C++ устроиться... хоть за еду/проезд, а то перейти то с него можно на C# или Java можно, только куда ни глянь - кроме самих плюсов еще кучу всего знать надо.

аналогично год назад искал, но на то время (незнаю как сейчас), cудя по вакансиям в инете, везде требовались плюсовики с опытом работы как минимум от 2х лет, кроме того со знаниями STL/ATL/WTL и прочих библиотек, которые без опыта работы в полноте не постигнешь. Думаю, сейчас ситуация та же, лучше ищи вакансии .NET джуниора, тут ИМХО варианты есть и будут. К голому знанию C# обычно требуется SQL, XML как минимум, иногда ASP обязателен.
 
Ассемблер развивается и сегодня,расширяются макросредства,новые аппаратные решения расширяют состав команд.Написание консольных приложений на ассемблере сегодня более
актуально,чем написание оконных по причине малых затрат(нет необходимости создовать
обьекты,описывать классы окон ,заниматься их регистрацией,создавать карты сообщений, и т.д),зато доступны практически все возможности WIN32 API.
Я не за ассемблер как панацею,но рекомендую каждому написать по одному средней сложности приложению,что даст освоить специфику аппаратных средств,некоторое представление о внутри происходящих процессах,сегментные состовляющие кода,свойства подчиненных и неподчиненых
сегментов ,формирующихся при системных вызовах и обработке прерываний.
Настоятельно рекомендую при выборе для изучения языка програмирования воспользоваться советом,который вытекает из ниже описанного примера.
Представте себе,что нужно анимировать игру,суть которой в следующем:
Идет по улице солдат Онтебету,по обе стороны улицы помещения,где баришники Капулько ,ВМФ,
Музер создают великие прикладные пакеты.Поравнявщись с домиками,солдат забрасывает туда портянки,получая стиранные и продолжает путь до конца форома.
Низкий поклон разработчикам языка хххх,это предел совершенства,позволяющий в короткие сроки
анимировать игру с использованией технологий графики 2-3-х мерных пространств.
Задействованные при этом поцессы в большей мере скрыты,заэкранированы от разработчика игры.
Доступны и контролируемы им те процессы,которые дозволяет ему прикладной интерфейс.
Ну а если жара и портянки чаще менять надо и при этом передвигаться медленнее?
Тогда на помощь может прийти С++.Внедряя новые абстракции и обьекты,переопределяя функции,
используя динамику обьектов,свойство контроля по времени,по событиям,прерываниям от внешних задействованных устройств можно расширить возможности игры.Ну а если возникнет необходимость разрешения конфликтных ситуаций,которые могут возникнуть при обращении к одному обьекту в один момент времени в рамках одного процесса?
Тогда на помощь придет ассемблер,позволяющий через счетчик команд и времени выполнения
машинной инструкции по системному таймеру рассагласовать момент обращения к данному обьекту.
Спасибо за внимание.
 
А JVM или CLR не позволяют получить необходимый доступ? Скорость разработки побыстрее будет, да и такие прелести как сборщик мусора достаточно приятны. Чтобы писать на С++ качественные приложения нужно опыта и знаний побольше. Для разработки десктоп приложений С++ не пригоден, для веб тоже.

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

но с++ и есть та универсальна ясреда, на которой можно написать почти все... но для этого нужен опыт... и большой... поэтому, другие языки тоже надо знать, чтобы более простые приложения на них разработать, но все же предпочтение следует отдать плюсам.. ИМХО!
 
Написание консольных приложений на ассемблере сегодня более
актуально,чем написание оконных по причине малых затрат(нет необходимости создовать
обьекты,описывать классы окон ,заниматься их регистрацией,создавать карты сообщений, и т.д),зато доступны практически все возможности WIN32 API.

:eek: не понял, а что мешает писать точно такое же консольное приложение на C++? Описание классов окон и карты сообщений - это, как бы, требование операционной системы для GUI-приложений, а вовсе не языка.

Я согласен с тем, что представление об асме и о том, как работают "железо" и операционка на низком уровне - нужно и полезно. Но писать более-менее серьезный софт полностью на ассемблере - увольте. Даже известные своей любовью к асму и хардкорной оптимизации демомейкеры и то уже давненько по большей части пользуют С/С++, потому что в большинстве случаев современный компилятор обеспечивает приемлимую оптимизацию, да и многое из того, что раньше приходилось оптимизировать ручками, теперь вообще решается на аппаратном уровне. Вспомни хотя бы извраты с вычислениями с фиксированной запятой на 486х машинах без математического сопроцессора или хитрые алгоритмы закрашивания треугольника текстурой с моделью освещения Гуро до эры массового распространения графических 3D-ускорителей.

Ну а если возникнет необходимость разрешения конфликтных ситуаций,которые могут возникнуть при обращении к одному обьекту в один момент времени в рамках одного процесса?

Или я чего-то не понял в данном пассаже, или примитивы синхронизации (event, mutex, critical section и т.п.) никто не отменял, и пользоваться ими из C++ тоже не запрещал. Да и терзают меня смутные сомнения, что предлагаемый автором способ со счетчиком команд и системным таймером будет надежно работать на операционке НЕ реального времени с вытесняющей многозадачностью.
 
Ассемблер развивается и сегодня,расширяются макросредства,новые аппаратные решения расширяют состав команд.Написание консольных приложений на ассемблере сегодня более
актуально,чем написание оконных по причине малых затрат(нет необходимости создовать
обьекты,описывать классы окон ,заниматься их регистрацией,создавать карты сообщений, и т.д),зато доступны практически все возможности WIN32 API.
Я не за ассемблер как панацею,но рекомендую каждому написать по одному средней сложности приложению,что даст освоить специфику аппаратных средств,некоторое представление о внутри происходящих процессах,сегментные состовляющие кода,свойства подчиненных и неподчиненых
сегментов ,формирующихся при системных вызовах и обработке прерываний.
Настоятельно рекомендую при выборе для изучения языка програмирования воспользоваться советом,который вытекает из ниже описанного примера.
Представте себе,что нужно анимировать игру,суть которой в следующем:
Идет по улице солдат Онтебету,по обе стороны улицы помещения,где баришники Капулько ,ВМФ,
Музер создают великие прикладные пакеты.Поравнявщись с домиками,солдат забрасывает туда портянки,получая стиранные и продолжает путь до конца форома.
Низкий поклон разработчикам языка хххх,это предел совершенства,позволяющий в короткие сроки
анимировать игру с использованией технологий графики 2-3-х мерных пространств.
Задействованные при этом поцессы в большей мере скрыты,заэкранированы от разработчика игры.
Доступны и контролируемы им те процессы,которые дозволяет ему прикладной интерфейс.
Ну а если жара и портянки чаще менять надо и при этом передвигаться медленнее?
Тогда на помощь может прийти С++.Внедряя новые абстракции и обьекты,переопределяя функции,
используя динамику обьектов,свойство контроля по времени,по событиям,прерываниям от внешних задействованных устройств можно расширить возможности игры.Ну а если возникнет необходимость разрешения конфликтных ситуаций,которые могут возникнуть при обращении к одному обьекту в один момент времени в рамках одного процесса?
Тогда на помощь придет ассемблер,позволяющий через счетчик команд и времени выполнения
машинной инструкции по системному таймеру рассагласовать момент обращения к данному обьекту.
Спасибо за внимание.
сколько раз можно говорить, иди нахуй!
Given the persistence of assembly language even now in advanced development environments (MS Studio), one expects that a system ought to be a mixture of all the generations, with only very limited use of the first.
Посилання видалено

и, как уже писали, для разруливания целостности в многопоточном приложении ассемблер нахуй не нужен..
 
Назад
Зверху Знизу