X
次世代言語議論スレ[Go Rust Scala Haskell]第5世代 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
0688デフォルトの名無しさん
垢版 |
2017/08/11(金) 11:59:08.49ID:wWK8j68x
>>685
少なくともunsigned は要らなくない？
1bit ケチれるだけだし。
中途半端な単精度浮動小数点とかも。
0690デフォルトの名無しさん
垢版 |
2017/08/11(金) 15:03:12.85ID:Pc9UeBFi
>>686
まだコードを書いてないのに問題でしょとか言われても
言う時期が早すぎるし言う内容に具体性がないよ
まるで数学も英語もまだ知らない小学生にプログラミングを教えているようだ
0691デフォルトの名無しさん
垢版 |
2017/08/11(金) 15:39:55.52ID:Dik+7mIk
TypeScript触ってるとjsに型がある方が幸せだってわかる。
jsonにスキーマ設定無しで
reduxでstate管理するのとか絶望する。
あと、学習面でも明らかに型があったほうが幸せ。書いてる端から指摘してくれるからすごく幸せ。
TypeScriptはvscodeとセットで幸せー
0692デフォルトの名無しさん
垢版 |
2017/08/11(金) 15:58:37.67ID:uuzmQ1J4
>>688
今言ってる片野必要性は容量のためじゃないだろ
全ての引数をテストするとすると1bit減ることでテストの数が半数になる実装もその1bitに対して考える必要がなくなる
例えばルートを計算する関数を実装するのに引数が正の整数と限定されてれば簡単だが、負だったり小数した場合は複雑になる。文字列や画像だった場合は例外が発生したりアボートしたり誤作動するかも知れない。
型はビジネスロジックに集中するためのルール、制約だ
静的は言語レベルで強制、チェックしてて、動的ではユーザ、実行時に任せてる
0693デフォルトの名無しさん
垢版 |
2017/08/11(金) 18:06:45.60ID:wS48fUKa
関数の引数なんかはやっぱ型があった方が読みやすいなと思う。
でも内部のテンポラリ変数なんかは別にいらんかもね。
というかテンポラリ変数の型情報がないと読めないようなコードは
そもそもコードが長すぎるとか、他の根本的な部分に問題がある気がする。
0694デフォルトの名無しさん
垢版 |
2017/08/11(金) 19:32:48.58ID:L+PB1ux2
>>682
>>690
内容がフワフワしてて何言ってるのか理解できない
もっと具体的かつ簡潔に言え
Twitterによくいるプログラミングできないのにプログラム語ってるクソ野郎みたいだぞ
0695デフォルトの名無しさん
垢版 |
2017/08/11(金) 19:36:48.30ID:L+PB1ux2
>>688
unsignedはオーバーフローしても下から戻るから楽
つか実装型まで否定するって、じゃあ任意精度にしろってか？
計算量制御できなくなるぞ？
0697デフォルトの名無しさん
垢版 |
2017/08/11(金) 22:53:04.88ID:HT0ZPb79
西京漬けいいよね
0699デフォルトの名無しさん
垢版 |
2017/08/12(土) 08:33:13.28ID:Uq7dQQ/j
>>694
プログラミングできるできないではなくタイミングの問題
目の前のことを言えば具体的かつ簡潔になる
遠い将来のことを語るとフワフワする
0700デフォルトの名無しさん
垢版 |
2017/08/12(土) 09:39:33.11ID:DS1jvWO1
次世代言語を語りたければ、今流行ってる言語の分析をしないと
Java、C#、C/C++が人気だけど
0702デフォルトの名無しさん
垢版 |
2017/08/12(土) 11:28:39.85ID:lZqlh0rm
Java系は一貫した技術の枠内で一通り完結するのがメリット
アプリケーションロジックの開発に集中できる
0705デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:15:33.93ID:bnRf3zzW
>>700
Java…型推論ない、論外
C/C++…メモリ安全じゃないので面倒
C#…まあ使える。ただT aだったりT b()だったりで書き方がちょっと古い
0706デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:17:29.71ID:bnRf3zzW
C#は良い言語だと思うよ
パターンマッチが追加されたりifが式になったりで便利になってきてるし
0711デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:31:48.99ID:Z/LzjBMS
.net coreはまだプロダクションで使うのは怖いだろ
仮にそこ乗り越えたとしても、C#だと結局開発はVS最強なんだから窓開発になる
0712デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:32:59.46ID:bnRf3zzW
.NET CoreだけじゃなくてMonoもあるぞ
0713デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:38:41.45ID:ahseiZ+6
>>711
もう1年以上経つし、そろそろ.NET Standard2.0も出るこの時期に何言ってんだか
素直に知りませんでしたでいいよ
0715デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:46:02.46ID:bnRf3zzW
.NET Standardってなんや
0716デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:47:02.12ID:zLZ79VVH
見事にオープンソースとクラウドの時代を代表するリーダーの一人として転身を果たしたMS
存在感を失い続けるIBMとオラクル
そう考えるとJavaは疫病神なのではないか
0719デフォルトの名無しさん
垢版 |
2017/08/12(土) 14:54:08.03ID:ahseiZ+6
>>716
こないだのPaketの件といい、.NET CoreからFullの.NET Frameworkの一方的な切り捨てと言い、コミュニティをないがしろにしてちょいちょい炎上してるけどな
0722デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:00:15.90ID:2/FX67Cg
.NETはまだまだ環境の問題もあるからともかく、
MSだからという理由でMSのプロダクトが開発者に嫌われることは少なくなったね
マカーがMS製のエディタでMS製の言語でプログラミングしてそれをMSのクラウドプラットフォーム上でホストされてるLinuxへデプロイするとか　一昔前ならあり得ない未来だった
0723デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:03:25.03ID:DE4QKP9/
Monoで動いているものは結構色々あるはず
例えば3DGameEngineのUnityはC#で開発できるけど裏でMonoが動いてる
マルチプラットフォームな開発環境であるXamarinもMonoを使ってる。
知らないうちに.Netは大半のプラットフォームで動くように。
0725デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:19:13.69ID:953va2dM
.NETはLLVMつかってネイティブ化する計画なかったのか
0726デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:24:30.75ID:DE4QKP9/
実際のところ.Netを選ぶメリットって何かあるのかな？
マルチプラットフォームならtypescriptとelectron、もしくはreact nativeで良い気がするけど。
0727デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:25:59.19ID:953va2dM
現行、LLVMの使用はLinux、Macのみらしいが原理としてLLVMが動くすべてのOSでネイティブコンパイルできるのでは?
実際動かしてないし間違えてるかも。


性能を強化した「.NET Core 1.1」が公開　2016年11月21日
米Microsoftは11月16日、「.NET Core 1.1」を公開した。性能が強化されたほか、対応するLinuxディストリビューションも拡大した。
最新版では対応するディストリビューションを拡大し、Linux Mint 18、OpenSUSE 42.1、macOS 10.12、Windows Server 2016で利用できるようになった。
macOS 10.12とWindows Server 2016については、.NET Core 1.0も利用できる。
Linux向け、Mac向けでは、CoreCLRをClang/LLVMでコンパイルするため、次のリリースでClang版のPGOをサポートする予定としている。
https://mag.osdn.jp/16/11/21/154500
0728デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:33:46.06ID:D9kn9WR2
まあ実際使ってみると右往左往することになるわけだが。
「互換性」あるってセールストークに馬鹿みたいに引っかかりすぎなんだよ。
0730デフォルトの名無しさん
垢版 |
2017/08/12(土) 20:42:05.60ID:953va2dM
こういう流れらしい。


.NET Coreとは？　2017年6月6日

.NET Coreがリリースされて約1年経ち、ようやくビルドツールも正式版としてリリースされるに至った。
本連載記事では、「Linuxを中心にクロスプラットフォームで開発できる.NET Core」という視点で、開発の方法を説明していきたい。

.NET Coreの歴史
Windows上でのみ動作する.NET Frameworkは、2002年に最初に登場して以来、バージョンアップを重ねてきた。
それに対し、Windows・Linux・macOSで動作するクロスプラットフォームな.NET Coreが発表されたのが、2014年11月12日のことである。
このとき、今までWindowsのみをサポート対象としてきた.NETが、LinuxやmacOSもサポート対象としたことに加えて、最初からGitHubでオープンソースとして公開されたことにも驚きがあった。

クロスプラットフォームを動作環境とすることに関しては、Monoプロジェクトという先人がいた。
Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、その中にはGUIフレームワークも含まれている。
Monoプロジェクトは現在、Xamarin社が開発・サポートをしており、スマートフォン向けのクロスプラットフォーム開発環境であるXamarinブランドの製品を提供している。
そのXamarin社が、2016年にMicrosoft社に買収されて今に至っている。

Monoが.NET Frameworkそのものと互換性のある環境を目指していることに対し、.NET Coreは.NET Frameworkのサブセットとなる機能をクロスプラットフォームで提供することを目標としたわけである。
そして、.NET Coreの発表から約1年後の2015年11月5日にRed Hat社がMicrosoft社と協力し、Red Hat Enterprise Linux上での.NETのサポートを発表した。

.NET Coreの特徴はいくつか挙げられるが、ここでは特に「クロスプラットフォーム」「オープンソース」「軽量」「フレキシブル」の4点について強調したい。
http://www.buildinsider.net/language/dotnetcore/01
0733デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:09:25.46ID:5ZVaRTG/
>>728
Javaも同じだけどね。
お陰で一度書けばどこでも動くって宣伝文句も、一度書けばどこでもテストが必要って揶揄されて久しい。
HTMLも然り。
実はHTML5+JavaScriptのが動的言語な分タチが悪いっていう。


>>726
TypeScriptもMS製ですよ。
VS Code出したし、.net Standerd出たしってなると、VC#のマルチプラットフォーム化が始まりそうな予感はするが。
(MonoでC#のマルチプラットフォーム化はしてるけど、C#の良さはやはりIDEであるVSあってこそ)
0735デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:21:36.37ID:LJmg41iW
typescriptがMs製なのは知ってるよ。
そして素晴らしいのはtsserverを同梱してること。
言語自体にリファクタリングや定義箇所への参照機能等ideに必要な機能を同梱させたんだよね。

この仕様をlanguage server protocolとして標準化しようとしてるのも素晴しい。
ide側で言語仕様を把握する必要がなくなり、上記のプロトコルを解釈する機構を用意しておけばいい。
0736デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:25:12.33ID:LJmg41iW
ぜひともlanguage server protocolを言語側で用意するのを必須にしてほしい。
新興言語ほど補完機能が弱いことが多いから。goの補完が効くようになったのもここ二年くらいからだったし。
0737デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:28:03.98ID:5ZVaRTG/
マルチプラットフォームの夢も分かるけど、現実的じゃないんだよね。。。
一個のOSでさえバージョン違いで互換性崩れるのに、それを複数とか。
現実的にはテストの都合でプラットフォームもバージョンもグッと絞らないと死ねる。
0738デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:53:43.57ID:47VquCRx
MSはLinuxの技術者が食いついてきたらLinuxがクソになってきたので独自拡張LinuxまたはWindowsのみのサポートにしますって言って利益をあげるんだろ
知ってるんだから
0739デフォルトの名無しさん
垢版 |
2017/08/13(日) 00:57:05.96ID:PA7iDDOj
>>730
これアレじゃね？
競合しそうな会社を買って手中におさめて
コントロールするか飼い殺しにするかっていう
いつものMSじゃね？
少なくとも
>Monoプロジェクトは.NET Frameworkの互換環境をLinuxやmacOSを含めたスマートフォンOSにすることを目標としており、
>その中にはGUIフレームワークも含まれている。
の部分はもはや怪しいというか
.NET Coreで行きたいんでしょ？MSは
0742デフォルトの名無しさん
垢版 |
2017/08/13(日) 01:22:18.67ID:GoIJeqVQ
次世代言語ってなんなんだ？

Cの次世代言語がC++だと言われれば納得できる
c++の次世代言語がjavaだと言われればちょっと首を傾げながら納得する

javaやc#などの次世代言語が　Go Rust Scala Haskellだと言われたら
全く納得できない
0743デフォルトの名無しさん
垢版 |
2017/08/13(日) 01:49:44.40ID:PA7iDDOj
そりゃそうだ
次世代というなら、シェアをひっくり返すかトントンぐらいまで行かないと
次世代とは言えない
というか、そういう状況にならないと
業界が何となく全体的に次世代に移った、とは言えない
なら次世代とは何なんだ、「世代」とは何なんだ
来もしないであろう架空の未来のことを
「次世代」と言っても仕方がないではないか
C++の次世代という触れ込みだったD言語は言語仕様的にはそうかもしれないが
全然普及しなかったからC++の次世代だ！っつってもふ〜んって感じだし
そんな「世代」は来なかった、って感じ
0744デフォルトの名無しさん
垢版 |
2017/08/13(日) 01:52:23.84ID:PA7iDDOj
結局はJava、C#、C++などの現世代の王道言語が順当にバージョンアップして
移行が行われたら、その地点が「次世代」って事になる
0745デフォルトの名無しさん
垢版 |
2017/08/13(日) 03:22:34.66ID:xz6n1XH5
互換性のためだけのレガシー構文が積み重なるわ不自然な拡張方法になるわ
で最終的にperl5みたいな「これでなければなんでもいい」になるんですね？
0746デフォルトの名無しさん
垢版 |
2017/08/13(日) 06:40:32.63ID:LJmg41iW
構造化プログラミング -> オブジェクト指向 って進化は基本的に
制約をきつくしていく傾向だよね
だから次世代はもっときつくなる。

多分参照型の消滅が次世代の考え方になるのかなと思う。
次世代っていうか関数型の話だけど。
参照型って結局ポインタ型つまり機械語にかなりよった概念だと思う。
これのせいで値の比較とかが難しくなる
インスタンスの内容が同じなのに == で評価したら不一致。みたいな。

参照型って結局メモリ節約のシンプルな解決方法にすぎない。
Immutable.jsとかみてると内部構造をメモリ節約できる仕組みにして隠蔽するとこで表向きは値型にしてる。こういうことができるんだから全部値型で構わない。
0747デフォルトの名無しさん
垢版 |
2017/08/13(日) 10:11:59.72ID:Zj27tgiX
>>745
perlは役に立つぞ
役に立つという条件さえクリアすればなんでもいいという単純な時代もあったんだろう

今は役に立つだけでは不自然と判明したから更に複雑な条件が追加されていくだろう
0750デフォルトの名無しさん
垢版 |
2017/08/13(日) 11:50:48.27ID:Zj27tgiX
シェルスクリプト系はカーネルにフリーライドしているくせに
そのことを全く気に病む様子がない

Java系は自己完結とかOSを作りたいとか自分自身をコンパイルしたいとか煩悩が多い
0752デフォルトの名無しさん
垢版 |
2017/08/13(日) 22:30:38.39ID:ZLPpL5wN
>>750
いろんなものに手を広げずにシンプルな仕様だけを用意していた方が
結局互換性が高いってことだね。
0754デフォルトの名無しさん
垢版 |
2017/08/14(月) 05:55:23.82ID:92xt4hcL
Mono(.NET)と、.NET　Coreの用途の違いは、すでに100%.NET環境が移植できていれば.NET　Coreの出番はないはずだが。
そうではない環境では、その環境を構築なしに移植できるってことか。
C#のコードをLLVMのアセンブラに翻訳したらあとは既存LLVMに丸投げできるから、移植コストは低く共通化できる。
0755デフォルトの名無しさん
垢版 |
2017/08/14(月) 08:53:13.99ID:+p07mcQa
＼＿＿＿＿＿＿　　＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿／
　　　　　　　　　　　○
　　　　　　　　　　 Ｏ 　ﾓﾜﾓﾜ
　　　　　　　　　　o
　　　　　　　　∧＿∧！　ﾊｯ!　　 ／￣￣￣￣￣￣￣￣
　　　　＿＿_（　 ゜∀゜）＿　　　　＜　という夢を見たんだ
　　　　|　 〃( つ　　つ　 |　　　　　＼＿＿＿＿＿＿＿＿
　　　　|＼ ⌒⌒⌒⌒⌒⌒＼
　　　　|　 ＼＾　⌒　　　⌒ 　＼
　　　　＼　 ｜⌒⌒⌒⌒⌒⌒｜
　　　　　 ＼ |.＿＿＿＿＿＿__|
0756デフォルトの名無しさん
垢版 |
2017/08/14(月) 09:01:00.79ID:l9TYt/P3
>>754
.NET CoreはCLR自体をアプリに同梱するように作られていて、AOTコンパイルではない
LLVM対応もJITをLLVMで実装しようというものに過ぎず、あくまでコンパイルはJIT
Coreは基本的にWebサーバー用だから少々起動に時間がかかろうが全く問題にならない
0757デフォルトの名無しさん
垢版 |
2017/08/14(月) 09:32:55.89ID:92xt4hcL
こんなのでてきた


Microsoft、C++技術で.NET Core 2の高速化実現　[2017/07/22]
Microsoftは7月20日(米国時間)、.NET Core 2.0で採用されている高速化技術「PGO (Profile-Guided Optimization )」について伝えた。
この技術はC++コンパイラでより最適化されたコードを生成するために使われているネイティブコンパイラ技術。
.NET Core 2.0にも同様の技術が適用されており、すべてのユーザは特定の処理をすることなくこの高速化技術の恩恵を受けていると説明している。
http://n.mynv.jp/news/2017/07/22/096/images/001l.jpg
http://n.mynv.jp/news/2017/07/22/096/images/002l.jpg
http://news.mynavi.jp/news/2017/07/22/096/



Microsoft、LLVMベースの.NET/CoreCLRコンパイラLLILCを発表
2015年5月6日
.NET FoundationがLLILCという新しいプロジェクトのリリースを発表した。
このプロジェクトはもともとMicrosoftによるもので、.NET Coreのための新しいLLVMベースのネイティブコードコンパイラを提供することを目的としている。
これによって「CoreCLRが移植されていてLLVMがターゲットとしているプラットフォーム上で」.NETプログラムを動かせるようになる。
LLILCのロードマップによると、Install-Time JITコンパイラが次のターゲットだ。「これは生成されたコードを、
1つのアプリケーションの複数の呼び出しの間で、または1つのアセンブリセットを共有する複数のプロセスの間で共有できるようにする」。LLILCプロジェクトでは、Ahead-Of-Timeコンパイラの実装も検討している。
https://www.infoq.com/jp/news/2015/05/microsoft-llilc-llvm-compiler
0758デフォルトの名無しさん
垢版 |
2017/08/14(月) 13:38:56.86ID:kXWZXT9S
>>742
世間で言われてる分類で言えば全部第3世代言語だからな
他でドヤ顔で言ったら恥ずかしいぞ
0759デフォルトの名無しさん
垢版 |
2017/08/14(月) 13:42:18.27ID:kXWZXT9S
>>742
世間で言われてる分類で言えば全部第3世代言語だからな
他でドヤ顔で言ったら恥ずかしいぞ
第4世代はユーザが使う言語

JavaはC++--って言われるくらいで先進性よりも普及を重視してたんだろ
今はもう滅茶苦茶だが
でC++++でC#と
0760デフォルトの名無しさん
垢版 |
2017/08/14(月) 14:14:03.57ID:C7avT2pN
次世代はサービスインテグレーションのための超高レベル言語だろうな
ドメインスペシャリストと開発者の間の垣根を無くすことと、強力なサービス連携がポイントだと思う
0763デフォルトの名無しさん
垢版 |
2017/08/14(月) 17:28:12.75ID:wnsRSkHP
でもまぁ方向性としてはありかと。
結局プログラミング言語ってツールなわけだから
何かに特化したほうが仕事はやりやすくなる。
DB設計したらwebAPIの定義と処理が自動実装されるようなDSLとか欲しい。

golangのgoaとかAPI設計からGoのコードを自動設定するから近いっちゃ近いけど
DB周りとの連携はまだイマイチかなと。
0765デフォルトの名無しさん
垢版 |
2017/08/14(月) 19:20:45.04ID:Ib/9zFrg
自動でコード出力する系は嫌い
改造するの面倒だし
マクロみたいなのが好き
0768デフォルトの名無しさん
垢版 |
2017/08/14(月) 22:37:21.06ID:wnsRSkHP
でもgoaは割ときれいなコード書いてくれるから、結構勉強になるし、生成ファイルとは別ファイルにして動作をカスタマイズする前提だから、
マクロとそんなに変わらないと思う。
マクロよりマジック感が減るから処理を追いやすいし
0769デフォルトの名無しさん
垢版 |
2017/08/14(月) 22:47:09.43ID:kXWZXT9S
コード出力ってそのあと追記とかするの?
戻れなくないか

いっそバイナリ吐いてくれた方がよくないか
0770デフォルトの名無しさん
垢版 |
2017/08/14(月) 22:55:39.38ID:O7NIduQl
糞バカペチプァにそんな知能あるわけないだろ
やつら、次に食べる飯と寝ることくらいしか頭に入らない小頭症のガイジだからね
0772デフォルトの名無しさん
垢版 |
2017/08/15(火) 00:47:06.80ID:Iy2AbH2m
>>769
それじゃ混ぜて最適化できないし
APIの公開非公開の制御もできないじゃん
そらGPLとか仕事じゃないなら関係ないかもしれないけどさあ
0773デフォルトの名無しさん
垢版 |
2017/08/15(火) 00:48:49.86ID:Iy2AbH2m
>>771
いや流石にソースか出力どっちかはバージョン管理に入れるだろ
CIしてたらコンパイル通らなくなる
0774デフォルトの名無しさん
垢版 |
2017/08/15(火) 02:11:40.42ID:ucbHC/q/
まあいろいろな環境でも動かしたいとかいう理由で出力したソースを
コミットすることもあるけど、あんまりいいことないよ。。おすすめしない。
0775デフォルトの名無しさん
垢版 |
2017/08/15(火) 05:31:41.09ID:tN8D0FqC
>>769
もちろん生成コードとは別ファイルにカスタマイズコードを書くよ。
だからgitの管理対象外にするのが普通。
ただ、俺はあえて管理対象にしてるけどね。設計変更したときに自動生成コードがどんな変更をしたかわかりやすい。

マクロ系だとこういう部分が隠蔽されてると考えることができる。
デコレータとかもそうだよね。

goはジェネリクスとかマクロがない代わりにコード生成を推奨してる言語と言えるね。

最初は後退した言語だと思ったけど
コード生成と衝突しない書き方ができるから、マクロとかで裏でどういうコードが生成されているかを把握できる言語と考えれば悪くないなと感じてる。
0776あ
垢版 |
2017/08/15(火) 10:52:42.87ID:acuW3DAP
phpバカにしまくる奴が疑問。
言語としてはまあボロボロだけどnginxとphp-fpmより安定したサーバ書けるの？って聞くと黙ったり、
過去、ひどいコード書いたとか、ひどいコードの保守したとしか考えられん。
0777デフォルトの名無しさん
垢版 |
2017/08/15(火) 11:04:03.16ID:WUz8q6HI
nginxとphp-fpmより安定したサーバ書けるの？という質問が意味不明で黙るしかないよｗ
0781あ
垢版 |
2017/08/15(火) 12:46:45.72ID:acuW3DAP
実用に耐えてないじゃん？みたいな話。
Goのサーバも見たことあるし、ErlangもElixirもあるけど、ずーっと誰かが推してるウェブベースのアプリって見たことねえなあ、ってのが
>>770を見て>>776を書いた所以。
脈絡ないのは認める。すまん。
0783あ
垢版 |
2017/08/15(火) 13:02:18.16ID:acuW3DAP
>>782
そうでもないよ。普通にいわゆるSSIみたいな形で動的なコンテンツ差し込むサーバも見たことあるし、
逆にPHPでも1ファイル1機能のAPIサーバと静的htmlの組み合わせも見たことある。

後者とは競合すると思うんだが。
0786デフォルトの名無しさん
垢版 |
2017/08/15(火) 13:46:49.20ID:HWb5gMTo
このクソコテガイジだからな
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況