見出し画像

私のプログラミング言語遍歴

noteの話題を見ていると「プログラミングの始め方(始めました)」のようなものが多く書かれていることに気が付きました。そういうのを見ていて触発されてしまい、ふと、自分のプログラミング遍歴を書きたくなりました。

前提として、私のプログラミング言語遍歴はかなり特殊、ということをお伝えしておかなければなりません。時代も違うのであまり参考にはならないでしょう。でも、時代と共に、自分にあった言語を選んできたので、まったく後悔はしていません。

また、昔からプログラミング言語についての話題は宗教戦争みたいなことになりがちです。ここではそういう話しには興味が無く、どっちが良い、でなくて、単なる用途としての向き不向きであったり、使う人に合っているかどうかだと思います。

本来は、まず第一に作りたいモノ実現したいことが先にありきで、プログラミング言語はあくまでもそのツールとして最適かどうか、ということではないでしょうか。なので、大抵のプログラマは複数の言語を用途に合わせて使い分けています。

さらに言えば、小学生の子供をプログラミング教室に通わせる、と言った昨今の風潮には賛同しません。寧ろ、そんな時間があったら子供の頃から日本語・算数(数学)・英語、(つまり読み書きそろばん)をしっかりとやらせておくべきだ、と言いたいです。

プログラミングに向いている子供は、ノートパソコンを貸してやるだけで一日中勝手に弄ってます。親としては、環境を用意してあげるだけで良いのです。大事なのは強制したり否定したり禁止したり、余計な邪魔をしないこと。危険な事を避ける教育だけして、後は離れて見守ってやればよいだけです。

まぁ、数学をやる意義を知る、という意味で数学や論理を楽しく学ぶ手法としてプログラミング的なものを取り入れるだけ、であれば別に構わないと思いますが。親の願望を子供に投影して無理してやらされて嫌いになった、なんてことになっては元も子もありませんしね。

基本的には英語も同様で、強制しなくても私のように好きな奴はほっておいても勝手に勉強して上達していきます・・ただ発音だけは後からどうなるものでは無いので・・・。

以上、前置きでした。

さて、自分がプログラミング言語を初めて学んだのは、Windows 95/98の時代です。1999年頃ですね。ミレニアム前夜。

当時は、今と違って多種多様な言語があるわけでもなく、とてもシンプルな時代でありました。

今は言語の選択肢が多くなりすぎて、初学者はどれからはじめればよいのか、またはどれがどういう言語なのか、といったことを見極めるのが難しく、情報(「初学者向け」という名の初学者による超テキトー記事)も錯綜していて、とても混乱している気がします。

そういう意味においては今は変に敷居が高くなっているというか、大変そう、と感じます。一方で様々なことが充実してきて便利で、楽だなぁ、とも感じます。

自分がはじめてプログラミング言語の基本を学んだのは、C言語であります。

#include <stdio.h>

int main(void)
{
   printf("Hello World!\n");
   return 0;
}

「メモ帳」で書いて、DOSのコマンドライン(command line、Terminal)でコンパイルして実行します。

同時に、HTMLの基本も学びました。

<HTML>
   <BODY BGCOLOR="FFFFFF">
      Hello World!
   </BODY>
</HTML>

(上記サンプル、わざと当時の書き方で再現しています)「メモ帳」で書いて保存してブラウザで表示します。

今思えば、これは自分にとってとてもラッキーな事だったと思います。C言語は、現代のプログラミング言語のほぼ全てに通じるところがあって、Cで基本をやればだいたい他の言語を学ぶ上でのとっかかりがあります。また、コマンドラインの使い方を覚えたので、のちにLinuxを使う際にもまったく苦労を感じませんでした。

とはいえ、C言語を使ってなにか有意義なプログラムを作ったり、ということはありませんでした。

2000年当時、まだインターネットの黎明期とも言える時代でしたが、図書館ずきな自分にとってインターネット(ウェブ)がまるまる巨大な図書館のように感じて、特に、英語を使えた自分にとっては面白すぎてどっぷりはまり込んでいました。

そこでHTMLを使って自分も色々と「ホームページ」を作ってみるわけです。(当然ながら当時はブログなんてありませんので、HTMLで書いてFTPでファイルアップロードです)

「ホームページ」でちょっと動くようなパーツを作りたい時に、HTMLに加えてJavaScriptを使う必要がありました。今と比べると、当時のJavaScriptはブラウザについた邪魔なオモチャみたいな扱いを受けていましたが、まぁ実際その程度のものでした。


<html>  
 <head>  
  <script type="text/javascript">  
   function msg(){  
    alert("Hello World!");  
   }  
  </script>  
 </head>
 <body>  
  <form>  
   <input type="button" value="click" onclick="msg()"/>  
  </form> 
 </body>
</html>

自分はC言語で基本をやっていたので、JavaScriptにも特に違和感を感じずに入ることが出来たのですが、やればやるほどブラウザ毎の互換性問題にぶち当たり、JavaScriptを嫌いになるばかりでした。なにせ当時は、「ブラウザ戦争」の真っ盛りですから。今からでは想像もつかないほど大変でした。大変といっても、ブラウザの互換性に起因する、今となっては無駄な知識、無駄な努力が必要で、大変だったのですw
(参考:>「IEがヤバい本当の理由」)

そうこうするうちに、HTMLで「静的」なページから、「動的」なページ生成をやりたくなります。プログラムを使って、サーバー側で動的にページの内容を生成するCGIというやつです。掲示板プログラムとかで良くありましたね。

#!/usr/bin/perl

print "Hello World!";

当時は、ApacheというWebサーバーを動かし、Perlなどの言語を使ってCGIで動的ページを生成するのが主流でした。自分でもLinuxを入れて、Apacheを動かし、CGIを動かす環境なども構築していました。さらに、色々とやりたくなって、MySQLなどをのSQLサーバーを入れてPerl/CGIのプログラムからデータベースを使いだしたりします。

自分は当時、Perlのラクダ本の原書を読んで一生懸命勉強した覚えがあります。だからか、未だにあの本には不思議な愛着を感じます。LAMPLinux Apache MySQL Perl)全盛期の時代でした。

今でいう、「Web開発」の原型がここにあると言えますね。Web開発の基礎に触れる事ができたという意味で、ここでも自分はラッキーだったと言えます。現代的なクラウドの利用から入ってしまうと、裏で実際は何が動いているのかはじめはピンとこない人が多いのではないかと思ったり。

因みに、この頃、AdobeのPhotoshopやIllustratorを使ってWebデザインチックな事にもハマっていました。今でいう「Web制作」的な。

Perlの他にも、新たにPHPという言語も登場してきていたのですが、どうもピンとこず、当時はSSI(サーバーサイドインクルード)に毛が生えた程度、という認識でいました。当時の認識としては、多分、正しいw なにしろ、PHP自体が当時は、Personal Home Page(パーソナル・ホーム・ページ)を意味していたですからw まぁ、それにしてもその後、PHPがWordPressと共にあそこまで広まるとは想像していなかったです。

Rubyも登場してきてはいましたが、当時はまだ知名度も無く、自分もだいぶ後になってTwitterと共にRuby on Railsが話題となって知ったという感じでしょうか。Rubyは日本発の言語なのに、逆輸入されて広まったというちょっと悲しい話しなんですよね。

Perlはその後、OOPオブジェクト指向)の記法が広まり、書き方がガラッと変わる流れが起きます。OOP以降とOOP以前でPerl界隈の分断が起きた、というか。元々、"There is more than one way to do it" という色々な書き方が出来るというのがPerlのモットーでありましたが、ちょっとそれとも様相が違う感じでありました。

しかも、新しいバージョンのPerl6が登場し、Perl6では言語仕様がガラっと変わるよ、という話しがあり、Perl界隈が動揺します。しかし待てど暮らせど全然Perl6は出てこないw これがPerlから他の言語に流れる人が増えた切っ掛けとなったように思います。

今から思えば、ブログの元祖、Movable Type に始まり、Perlで作られたブログシステムが世の中を席巻した時代がPerlの全盛期でもあったと思います。

因みに、Perl6は、サグラダ・ファミリアのように、10年以上ずっと完成しないネタになってしましたが、今調べたら、結局2019年にRakuと名前が変更され、Perl系の新たな言語として登場していました。(もはや完全に別物w)

さらに余談ですが、今日本で話題の台湾のオードリー・タン氏は、Perl界隈では昔から有名な人で、色々なPerl moduleを書いていたりして貢献し、Perl6(現Raku)の主要な中心人物として、知る人ぞ知る人物でありました。自分はその頃からオードリー・タンの存在を知っているのが自慢なのですが、誰に対してもなんの自慢にもならないというか、それだけwの話しであります。

当時、Javaという言語も登場していたのですが、"Write once, run anywhere"という宣伝文句が、嘘っぱちに感じて、良い印象はありませんでした。そもそもJavaランタイムを入れてる環境じゃなきゃ動かないし、起動はクソ重いし、Java swingなんて使い物にもならないし、Java appletも同様で、Flashの方がよっぽどマシ。サーバーサイドでもPerlでサクっと作れるものをクソ面倒くさくやっている、という事で、手を出す必要性すら感じませんでした。前宣伝倒れ、みたいな。今ではとっくの昔にswingもappletも消えて無くなっています。

とは言え、当時としては、Web開発を大人数でやる業務系に限って言えば、やはり静的型付けの言語が便利ですし、他に選択肢も多くなく、C++でやるには敷居が高過ぎて、Javaなら、という理由で選択するケースも多かったように思います。当時の空気としては、ITゼネコンが安く人を集めて多くに使わせる為の言語、という感じ(個人的感想)。

そんなんで、猫も杓子もJavaという雰囲気で、逆にPerlやPHPでやればサクっと超簡単な案件なのに、無理してJavaでやって大ゴケしているようなのまでありました。今では他の言語の選択肢も色々と増え、私は結局Javaやらずに済んでますw

Web開発と並行して、「デスクトップアプリ開発」というWindows上で動くGUIアプリケーションの開発もあるのですが、当時のマイクロストの開発環境Visual StudioではC/C++VB(Visual Basic 6)の二択でありました。(.NETなんて登場したばかりの頃でまだ原始的だった)

自分は、基本はC言語でやったとはいえ、デスクトップ開発においてC/C++でWindowsのGUIプログラムをWindowの生成からチマチマとコードから作るのは途方も無くめんどくさく、自分にも向いていないと判断し、VBの方がビジュアルにデザインできるし、生産性が高い、と未来を感じました。

ここが一つの分岐点で、本来、理系のエンジニアであれば、C/C++でもバリバリやっていくべきです(この辺りのことは「基礎技術をやるエンジニアが日本で少ない現状を嘆く」で書いています)。VBは生産性が高かったですが、制約も多く、低レイヤーの事が出来ません。ただ、業務システムのようなGUIアプリケーションをちょちょっと作るのにはVBは最適でした。

Private Sub Command1_click()
 Label1.Caption="Hello World"
End sub

VBでも幾つかアプリケーションを作りましたが、ちょっと凝った事をしようとすると、Windows APIを叩かないといけなくなるのですが、VBはそもそもそういう作りになっていないので、非常に無理がありました。C/C++では生産性に難があり、VBでは柔軟性に難がある。もっとこう、ちょうど良い言語はないものか・・・、と。

Delphiであります。Delphi言語は、ネイティブコンパイラの言語でありながらも、VBのようにビジュアルにGUIをデザイン出来るくせして、C/C++言語のようにポインタも使えてシームレスにWindows APIを使えるうえに、オブジェクト指向言語であり、コンポーネント指向でもあるという、当時から先進的かつ柔軟性があり生産性も高いという言語でありました。おまけにC/C++やVBで問題となっていた「Dll地獄」からも解放されました。

最高やん。

program HelloWorld;

begin
 WriteLn('Hello World!');
end.

マイクロソフトは、そんなDelphi人気に嫉妬し(たか知らんけどw)、Delphiを作ったアーキテクト、アンダース・ヘルスバーグを引っこ抜き、新たな言語、C#を作ります。これ、知らない人が相当多いです。今Web開発のフロントエンドで大人気のTypeScriptというJavaScript系の新しい言語もこの人がコアメンバーとして作っているとかいう、もう凄い人。

なので、C#もTypeScriptも、根底にはDelphiでの思想と仕組みが色々なところに垣間見えて、とても面白いです。自分はここでもラッキーだったな、と思います。

Delphiでは本当に色々と勉強させてもらい、とてもお世話になった言語であります。Delphi 6からDelphi 2010の頃まで使いました。自分が作ったソフトウェアの数もDelphi製が一番多いです。

そんなDelphiでありますが、唯一の欠点があります。マイクロソフトの製品では無い、という点です。Windowsの最新のOSの新機能にはどうしても対応が遅れます。また、一企業の言語、それもマイクロソフトでないサードパーティーだと、どうしても広がりが出ないんですよね。コミュニティも一定以上は広がらないというか。

しょうがないので、Delphi繋がりでC#も学びました。C#はDelphiと同じ人物が作ったんで、その裏にある思想とかフレームワーク的には似ていて、自分にとってC#はとても楽でした。

using System;

namespace HelloWorld
{
   public class Program
	{
       public static void Main(string[] args){
           Console.WriteLine("Hello world!");
       }
   }
}

一見すると、なんというか、構文的にはDelphiに名前空間を追加して、少しC風味の構文にアレンジした上で、クラスを必須にしたただけのようにも見えます。というか自分の中ではC#を学ぶ際にはそんな印象でしたw

C#におけるデスクトップ開発では、WPFというUIフレームワークとの組み合わせが最強で、XAMLというXMLベースの言語でデスクトップUIがウェブページ並みに自由に作れてしまうという無敵な存在であることが強みであります。

using System.Windows;

namespace WpfApp1
{
   public partial class MainWindow : Window
   {
       public MainWindow()
       {
           InitializeComponent();
       }
   }
}
<Window x:Class="WpfApp1.MainWindow"
       xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
       xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
       xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
       xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
       xmlns:local="clr-namespace:WpfApp1"
       mc:Ignorable="d"
       Title="Hello World!" Height="450" Width="800">
   <Grid>

   </Grid>
</Window>

あえて言うと、XAML単体でHTML+JavaScript+CSSのWebデザインみたいなことがデスクトップ開発のUIで出来てしまう、という感じ。その分、UIの作りこみがものすごく大変ですが、デザインとロジックが分離される効用はとても大きく、コードの保守性、応用性、再利用性などの優位点が沢山あります。また、きっちりと切り離されることで分業体制でも出来るため、UIはUIの専門に任せられますので、結果として良いものが出来ます。

最強です

ただ、UIが自由にデザインできる分、UI/UXに興味もないデザインセンスも無いような理系がやってしまうと逆に悲惨なことになったりします。Webデザインもやっててタグ打ちにも慣れている文系の私のような人間にとっては、WPFのXAMLはとても向いていました。

C#は、.NETフレームワーク上で動くので、C/C++のように低レイヤーの事は出来ませんし、Delphiのような柔軟性もありませんが、Windowsも含めて、UIデザインとUIトレンドの移り変わりが早い昨今、C#+WPFは最適解かな、と。因みに、Visual Studio自体も基本はC#/WPFで作られています。Visual Studio Codeの方でなく、大元のVisual Studio。

一方で、C#+WPFでは、XAMLによるUIデザインとの分離をする上で、従来のGUIでのイベント駆動の手法から、新たなMVVMというプログラミングモデルを学ぶ必要があります。XAMLとMVVMを合わせると、C#+WPFのとっかかりの敷居は高いと感じました。

その為か、C#+WPFで作ったアプリは一般向け・業務システム向けでも殆ど見かけません。古くはOOPで脱落する人も多かったようですが、最近ではWPF(XAML+MVVM)へのパラダイムシフトで脱落する人も多いとか。

このWPFのMVVMのプログラミングモデルは、今や、Web開発やモバイルアプリ開発にも輸出されて、先進的な最新の開発を行う際にはどこでもメジャーなアーキテクチャー・デザインパターンの一つになっています。

因みに、C#+WinFormsVB.NETという選択肢も未だにありますが、これらは基本的に、旧来のVBの制約がそのままで、あまりやる意味を感じません。というか将来性もゼロです。UIと密結合してしまっているので、こんなんで作ってしまったら後でどうにもならなくなるので、触るのはやめた方がよいです。

未だにWinFormsやVB.NETオンリーでやっている人がいたら、ヤバいと認識すべきレベルですが、業務システムを単に仕事で作らされているだけの人達でなんちゃっての人達においては結構いるようです。もしITゼネコンからそんなの提案されたら、突っ返してやりましょう。

そんななか、衝撃的なことが起きます。

Windows 8の発表です。「Metro UI」(意匠の問題で後に「Modern UI」に改名>さらに後でFluent Designへと移行)という、マイクロソフト史上最悪の方針転換を行い、デスクトップOSというより中途半端なタブレットOS化をしてしまったのです。

同時に、WPFモドキでとても中途半端で劣化版と言えるUWPという新たなアプリケーション形態も発表し、これをWindowsにおける既定と位置づけました(後に撤回)。UWPは、iOSアプリやAndroidアプリに対抗したWindows版という位置づけで、Windows Phone向けの携帯アプリ向けなどとして制約がガチガチな上に、デスクトップ向けの機能が欠如していたからです。

この事件により、デスクトップ開発をしていた人達が、一斉にWeb開発へ流れます。Ajax全盛時代でしたしね。自分もWindowsの将来すら考えたものです。Linuxへ行くか、Macへ行くか、みたいな。ソフトウェア開発者にとってはそれほど大きな方針変更でありました。

因みに、自分としては、ちょうどこの時期まったく別の業種にいたのでプログラミング自体まったく出来ないでいた頃であります。自分にはこの前後7年以上のブランクがあるのです。

観察するに、中には、「モバイルアプリ開発」へ行く人も居たようです。ただ、自分はモバイルアプリについては、別の所で書きましたが色々な理由があって作りたいとも思わず、AndroidのKotlinにしても、AppleのSwiftにしても結局手を出してません。

そもそも、どちらも移行元の言語があり、元言語との互換性の為に少々癖があり過ぎて、特化した専門で行く為に学ぶならまだしも、汎用言語としてはちょっと難があります。まぁ、逆に言えば、AndroidやAppleの環境で良いものを作りたい、というのであれば、選択の余地なく、KotlinかSwiftという事になるでしょう。

ただ、モバイル開発では、Googleが出した、Dart言語を使うFlutterというクロスプラットフォーム開発環境も出て来て人気が高まる一方で、今後KotlinやSwiftがどこまで広がるかは未知数な所があります。SwiftはMacOSでの開発という生き残り方法がありますが、Kotlinは・・・(Compose Multiplatformという話しもあるけれどあまり信用してない)。

マイクロソフトのWindowsに話しを戻すと、ご存知のように、今となっては、Windows 8はマイクロソフトの中では完全に黒歴史であり、Windows10をリリースして180度方針転換しています。Windows Phoneも消えました。マイクロソフト自身も今、一生懸命に書き直して、UWPを捨てている作業中です。

当然ながら、自分はもとからUWPなどと言う中途半端なもので何かを作るつもりは無く、ずっとC#+WPFです。今ではほぼこれメインで開発していて、幾つか一般公開しているものもあります。レビューでも五つ星を頂いているし、自分も作る上で特に不満はありません。

因みに、C#やC++で利用できるWinUI3(WinUI 3 - Project Reunion 0.8 Preview)という新しく登場する予定のWindows UIフレームワークもありますが、これは(試したけど)まだまだ未熟です。WPFの自由さを超える事もなさそうな雰囲気。(とはいえ、新規アプリはWinUI3で作ってる)

C#単体(GUI無し)で言えば、LinuxやMacでも動きますし、サーバーサイドというかバックエンドでも、AmazonやGoogleそして当然Azureのクラウド側の対応でC#が使えるようになって久しいです。サーバーサイドと(デスクトップ)クライアントサイドで同じC#言語のコードベースで開発出来ちゃうとかもう楽をし過ぎです。(ブラウザ)クライアントサイドとしてWebAssemblyもC#のBlazorで一応はできちゃいますしね。

さらに、C#でLinuxやMac向けのGUIアプリケーションを開発できてしまう、というAvaloniaや、Unoといった開発環境も出て来て、まだ未熟ながらも、将来的にはC#+XAML系のデスクトップ開発はクロスプラットフォーム化する可能性もあります。ムネアツ。(一応、Delphiも最近はそういうのが出来るようになってるようですが、試してません)

あと、クロスプラットフォームと言えば、Delphi言語のオープンソース版という位置づけのObject Pascalがあります。一企業が作っているものではなく、Lazarusというオープンソースの統合開発環境(IDE)があり、"Write once, compile anywhere"という一度書けばどこでもコンパイルできる、という特徴があります。基本的なものであれば、Windows、Mac、Linux向けのネイティブなGUIアプリケーションが単一のソースコードで簡単に作れちゃったりします。数年前に、これを利用して実際にアプリを作ったりもしています。ただ、本格的なGUIをクロスプラットフォームでやるのは色々な面での制約があって厄介です。

Pythonという選択肢も以前からありましたが、PythonでのGUIは付けたし感もあり、やはり色々と面倒で制約も多くありますし、自分はDelphiやC#やPerlを使っていたので、Web開発用としてもなんにしても、自分にとっては学ぶ必要性も特に感じずにきています。最近では機械学習(ML)向けのライブラリが多いから、という理由でPython=機械学習、みたいなことになっているようですが、自分は機械学習を専門にしてやるつもりもないので、触っていません。統計や機械学習に特に興味がある方にはPython良いのではないでしょうか。お手軽なWeb開発向けとしても盛んですし。

お手軽Web開発向けと言えば、あとはPHPRubyですが、自分はPerlをやっていたので、特に本格的にやる必要性も感じず・・・。そもそも動的型付け言語はもういいや、みたいなw

Go言語はといえば、最近の言語でGoogleが出しているところからも分かるように、どちらかというと、サーバーサイドやインフラまわりで便利そうな言語的な特徴を感じます。自分はサーバ管理チックなバックエンドやネットワーク系はやらないですし、Goも触ってないので実際の所はなんとも言えませんが。サーバーサイド専業でもない限り、C#などをやっていればわざわざGoをやる必要性も特にない気がします。ただ、今からJavaをやるくらいだったら、Goをやっといた方が良いような気もします。

Rustについては、既に書きましたね。

マイクロソフトからは近い将来、WPFのXAMLの亜種を採用する、 .Net MAUIというのが新たに出る(現在はPreview 5)のですが、これはC#で、Windows向けのみならず、AndroidiOSmacOS向けのアプリを単一のコードベースで開発出来るようにする、というクロスデバイス、クロスプラットフォーム対応を謳う野心的なもので、正式版が出たら触ってみるのを楽しみにしています。逆にUWPのような宣伝倒れなら内心ケチョンケチョンに言ってやる予定ですw 

モバイルアプリ開発では、C#の.Net MAUI+BlazorがDartのFlutterを追撃する感じであります。実はFlutterも少し興味はあったのですが、.Net MAUI + Blazorで同じことかそれ以上が出来てしまうのであれば個人的にはそっちで十分かなと。

Web開発の方でも、フロントエンドでの言語は最近になってTypeScriptに集約されつつあるようで、アンダース・ヘルスバーグの手の平で転がされているDelphi>C#系統できた私は、それを見ながらニヤニヤしている所であります。

じゃぁもう新たな言語は学ばないのか、というと、分からんです。

もう若くはないので億劫というのもありますが、新たに作りたいものが特になくなってきた、ということもあります。過去に作ってきたアプリの面倒も見なくてはなりませんし。

今の時代、大抵のものは既に誰かが作っています。そういう意味では若い人達は可哀そう、と思うこともあります。

最近では、一口でプログラミングと言っても、分野が細分化し専門性も高く複雑化しており、分業体制が進んでいます。ひと昔前なら一人で全て出来ていた事が、今では大まかに「ウェブ開発バックエンドフロントエンド)、モバイルアプリ開発アプリ本体バックエンド)、デスクトップ開発」に分かれ、バックエンド以外、それぞれロジックとUIとの切り分けも行われています。言うまでもなく、それぞれに向いた言語というのも違ってきます。

これらは誰でも簡単に始めて参入もしやすい分野でもありますが、専門で一つに特化していくと、固有のプラットフォームに縛られ、全体像も見えず単なる「ユーザー」に成りきってしまう恐れもあるので、やはり注意が必要だと感じます。仕事にするなら、少なくとも複数の全く違う分野はやっといた方が良い(つぶしが効くし、視野も広くなる)かもしれません。

既成の(他人が作った)プラットフォームを利用しているだけの「ユーザー」のままで満足してしまう、という罠にも陥りやすい問題は、「基礎技術をやるエンジニアが日本で少ない現状を嘆く」で書いた通りで、若い理系の人達は、CS(コンピュータ・サイエンス)の基礎をしっかり学んで、低レイヤーの方にも注目してプラットフォーマーに成れるよう頑張って欲しいなぁと思うのです。

プログラミングの分野には他にも、地味で昔から存在する「組み込み系」や「ネットワーク・通信系(あんまりこういう表現はしないけれど)」などの低レイヤーの分野もあります。これらはハードウェアと深く連動するので、理系人間とC/C++の独壇場です。今後も、自動運転システムなど、重要になってくる分野でもあります。

例え「ユーザー」であったとしても、異業種(非IT業界)においては出来る事が沢山あります。寧ろ、今後はどの業界でも何らの形で必要になってくるでしょう。

何をやるにしても、まず、作りたいものが何かあれば、言語も覚えられます。基礎をやっておけば、どんな言語もなんとかなるし、色々試せば自分にあった言語も見つかるはずです。

皆さんも、自分にあった言語を見つけられますように。

オッサンからは以上であります。


この記事が気に入ったらサポートをしてみませんか?