当我和我的朋友去上学，只梦想成为一名开发人员时，我们就想到了如何一起创造东西-一个游戏或一个超级有用的程序。
我开始学习专家和C＃，它是JavaScript。 我们高中毕业，在大学学习，在部队服役，找到了工作。 我们到处都充满着工业发展的困惑，当我们都厌倦了它时，我们想起了我们的起点。
聚集了已经经验丰富的开发人员之后，我们最终决定制作自己的项目-二维视频游戏。 由于朋友是个干净的人，而且我的书堆很多，因此浏览器成为了我们显而易见的平台。 我以前只在TypeScript上开发前端，我们认为没问题，TS只是JavaScript的超集。 采取它，一切都会顺利进行。 不管如何 当我们开始讨论工作时，我们面临着令人难以置信的彼此误解的深渊。
因此，我看到了制作游戏的任务。 我就是这样-是的，我们有一种“游戏”，一种“库存”，一种“事物”，一种“地图”，一种“位置”。 我可以粗略地想象它们如何协同工作，描述它们，组装一个项目，然后一切正常。 编译器检查了我，我做对了所有事情。 接下来，我开始编写使用这些类型的代码。 由于它们的存在，对我来说要容易得多。 IDE会告诉我并检查错误。 如果该项目即将进行-很有可能正在运作。 我花了很多时间在类型描述上，这很好。 这是我的方法。
我的朋友想做相反的事情-立即编写代码，而不描述任何类型。 他还没有准备好将问题定义为类型家族。 我不想在此基础上继续前进，也没有将任务视为一组类，类型，记录或类似的东西。 在我看来，这简直是不可想象的。 我们俩在很多方面都是对的，只是我们每个人的正义都排斥了对方。
说真的，我们聊了好几个小时，但每个人都说自己的话，好像是用不同的语言说话一样。 而且你不能说我们的大脑不灵活。 就在一年前，我毫不费力地从面向对象转向功能世界，反之亦然。 而且，我花了很多时间学习JS，他正在学习几种静态类型的语言。
但是，该技术成为开发人员的第一种“战斗”技术，对它们的定义如此强烈，以至于两个有经验的成年人根本不愿意互相倾听。 在研究发展的多年中，我们的愿景变化太大，解决问题的方法根本无法协同工作。
结果，我们放弃了相互合作的想法。 立即想到，问题只存在于我们两个人中。 也许可以，但是我已经在业内其他人身上看到了这一点。
静态和动态类型有根本的不可调和的区别
我的代码回答了“如何使用它”这个问题，而对于习惯于动态键入的开发人员来说，这是一个代码-“它是如何工作的”。 两种方法都有生命权，并且有两种方法都可以使用，但只有一种可以走在前列。
对于完成了数百年开发工作的大型项目，静态是好的，对于小型团队的，经常需要只写代码的任务，它是动态的。 使用动态，可以在开发开始时节省时间和精力，而在开发结束时可以节省时间和精力。
将类型放在首位的想法严重影响了我对开发人员的想法。
在旅程开始时选择C＃，我将静态类型钉入了我现在正在遭受的世界观中。 看到任何问题后，我尝试将其解决方案作为一组交互类型和原理来提出。 在开发模块时，我首先要确定其操作的类型以及与环境交互的类型。 我什至不记得我以前是如何解决问题的。
所有Java编程培训都是有关类型设计和使用的培训。 .NET CLR-C＃运行时-基于类型和类型。 静态类型化是面向对象程序设计的中心（您好，来自JS的类，我认为您是不需要的）。 大多数OOP模式的规范实现都充满了Interface，这在动态类型化语言中是完全没有意义的。
模式本身是一种跨语言的东西，但是有人可以告诉我为什么在动态类型化语言中需要“状态”模式吗？ 那建设者呢？ 这些模式与开发无关，它们与类型有关。 类型和OOP有着千丝万缕的联系。
您无法基于类型来构建业务逻辑，但是在开发过程中您一无所知。 这就是为什么有一些前端供应商用难以想象的数量的单元测试来覆盖他们的代码，这些单元测试只是检查代码库是否存在类型错误。
众所周知，通过覆盖范围实现安全性只是一种幻想。 测试是手工编写的；根据定义，它们不如该语言内置的类型检查系统可靠。
这并不意味着不需要动态类型的语言（实际上，我真的认为不需要它们）。 这意味着使用它们时，您需要放弃OOP作为主导范式。 所有这些数据和操作上的统一都是为拥有静态检查的人准备的。
与我打交道的开发人员不相信静态类型的存在会改变开发方法，他们编写与动态语言相同的代码，并添加类型检查。 我认为这根本是错误的。 而在现代前端的情况下，这一点最为明显。
我知道批评前沿是一个禁忌话题。 有一天，我和我的朋友创建了一个AI，该AI可以在Twitter上诱骗所有人，而Brendan Ike则对此表示欢迎。 认真地说，JavaScript的创建者在评论中与我们的神经网络进行了斗争。
由于某些未知的原因，这些家伙根本不准备好生活在一个他们的愿景存在严重差距的世界中。 因此，我只批评那些冲进我绝对类型的项目并在那里下订单的人。
我们本可以生活在我们的小世界中，但TypeScript推动了我们
因此，我编写的代码由于类型而不能正确使用。 在项目中，我希望其他人也使用类型。 然后我的代码将按预期工作。 而且我不会故意涵盖所有滥用此代码的情况（因为键入会排除此情况）。 但是一个JS昵称进入了项目，使用了这种类型的地雷，将其包装在任何地雷中，然后开始不正确地使用它，从而导致细微的错误。
JavaScript开发人员坚信Typescript仍然是相同的JS，但是具有有时可以在需要时添加静态类型检查的功能。 事实并非如此。 该脚本的功能要强大一百倍，并且他们只对脚本功能的百分之三感兴趣。
最具破坏性的参数是TypeScript只是JS的超集。 但是实际上，即使您是该死的领导者之王，您也不得不将Typescript视为一种独立的语言。 因为这里我们需要一种不同的方法-静态而不是动态。
静态类型的主要优点是保证。 如果在一个模块中而不是在另一个模块中使用它，则只是花时间和精力在类型的描述和开发上，而没有得到任何保证。
在许多人看来，TypeScript是JS和Java之间的类型系统之间的折衷。 他不是妥协，他的类型系统很特别。
如今，前线的第二个工作都需要TS知识，这使一切变得更加复杂。 这导致JS开发人员表面研究Typescript的功能，并开始在其中编写代码，从而产生了大量有害的做法。 当他们确实不需要静态的类型检查，但他们将其强加给他们并破坏了它时，就会出现一种情况。 最终必须认识到，具有动态类型和静态类型的开发方法相互矛盾，这是无法混合的。
正如我所看到的，JavaScript是编写代码的一个非常好的工具，它可以解决问题而又不突出不必要的抽象。 其中最令人震惊的案例是制冰厂模式。 您可以将该实例提供给您的实例，并且可以不受运行时的影响。 如果我使用该工厂处理对象，它将得到相同的结果，但是当我尝试更改其中一个属性的值时，将出现异常。 只是WAT？！？
之所以出现这种模式，是因为战线在某些地方读到了关于酷不变性的知识，并决定将其拖入他们自己的语言中，但这绝不是为了豁免。 在Typescript中，我可以创建相同的工厂，但是在编译时禁止更改突变，并且没有任何例外。
另一方面，这是没有必要的，因为有纯函数式编程。 以F＃，Haskell，OCaml为例，我将其放在ReasonML上-禁止开箱即用进行突变。 但是，恐怕如果将前端提供给功能语言，它将立即开始对其进行现代化，并使行为看起来像JS。
因为选择键入是一条没有返回的路径。 所有的折衷解决方案都只给出折衷的错觉。 您可以将类型放在最前面。 我不知道一切会如何，开始同时并行地学习C＃和JavaScript。 但是现在我对自己的想法非常了解，以至于我看不到也不想看到动态类型的优点。 它们是我的视线，但对我而言，剩下的就是对它们视而不见，因为它们对我所生活的对我而言是陌生的世界的任何表现。 我知道我错了，但我现在需要在这里和现在工作，而且两极之间没有预算紧张。
因此，我不想寻求妥协，而是直接发言。 如果您刚刚开始学习开发，请从静态类型开始。