5 ms·

Now all of a sudden, having types and some standards to gather around doesn't sound like a bad idea anymore ;) I agree with one of the commenters: Lessons alre

• spion 10y ago
  With node, at least you have the option to easily migrate to TypeScript and get excellent tooling.
  • beders 10y ago
    if all the libraries you are using are as well...maybe.
    • spion 10y ago
      You can write definition files for libraries. A lot of libraries already have such files: https://github.com/borisyankov/DefinitelyTyped https://github.com/borisyankov/DefinitelyTyped If a particular library doesn't have one, you can write it yourself. In that case theres no need to model the entire library - you can only model the subset of functions / methods that you use.
      • popmystack 10y ago
        Or what if, hear me out, everyone just did that thing from the start?
        • spion 10y ago
          I do tend to start all my new node projects in TypeScript, yes.
          • Tarks 10y ago
            With TS do I have to have a spec for every third party code or can I import something and use it as-is, but not get the benefits of TS on that part of the code?
            • maattdd 10y ago
              You can do both.
              • popmystack 10y ago
                Seems like a silly conundrum to be in.
• Silhouette 10y ago
  Lessons already learned by older engineers (who went through similar woes with other languages/tools) are being re-learned again and again. If only that were true! I think the JS (and more generally web development) ecosystem today is more a case of those who do not learn from history being doomed to repeat it. The thing is, if you actually are Google or Facebook or Microsoft or Mozilla or Apple, you can throw huge amounts of resources at problems and produce sufficiently useful solutions regardless, and then you can do the same again a few months later if you need to. These are the kinds of organisations that set the tone for the whole community because of their sheer size and influence. However, their goals are not necessarily aligned with the rest of the web development community, nor will their approach necessarily work well for someone else.
  • beders 10y ago
    I think I didn't express myself correctly. Younger engineers are ignoring lessons learned and are thus forced to learn them again :)
    • Silhouette 10y ago
      Ah, I see. In that case, I think we agree!
      • mgkimsal 10y ago
        I think you're both saying something similar, but there's a "why" in there to connect: > Younger engineers are ignoring lessons learned Why ignoring them? Beyond the 'youth' factor directly, the signaling from the larger companies mentioned (google, etc) is that those lessons don't necessarily matter, and... look, google did XYZ, you can too (ignoring that they threw potentially 3-5x as many people at problem XYZ than you even have, much less justify). Maybe neither of you meant that, but that was the connection I just saw between your two comments.
        • Silhouette 10y ago
          Yes, that's basically what I meant. I think some of the highly visible projects from tech giants today are succeeding despite their approach to software development, not necessarily because of it, but a lot of the new developers coming into the industry lack the experience to realise that and think of these projects as examples of how things should be done. Every time I see some young developer posting on HN about how the code we write today only has to work for a year or maybe two at most, or how 10,000 lines of code is a large program, or how some high profile company's web site that is still fundamentally just forms and tables and an API for talking to a database is a complicated UI, I weep a little for the future of our industry and our lack of ambition. Of course things like performance and stability and standardisation and portability don't matter very much if all you ever do is hop from one small throwaway project to the next every few months. I think the culture around HN is unfortunate in this respect, because from a commercial point of view, it is an alluring idea to build some sort of trivial MVP, try and get crazy amounts of funding, and then if (and only if) you succeed, to throw it all out and start over. As a business strategy for building the next WhatsApp or Instagram, that's rational and perhaps quite effective. But it also contributes to the everything-is-expendable mindset that plagues our industry, and since the overwhelming majority of software development projects don't have the luxury of starting over every five minutes, I think it breeds a lack of respect for professional programming and the skills required to build good software without the benefit of an effectively infinite funding source from benevolent investors (or from the goose that keeps laying golden eggs elsewhere in the organisation). That might be OK for Facebook or Google, but I wonder how many other startups that fail could still have been very successful, albeit not in unicorn territory, if their developers had paid more attention to some of these issues. I wonder how much time humanity collectively wastes today just because software quality and reliability aren't taken seriously by too much of the industry.
• athenot 10y ago
  Those are all very valid points. However, having witnessed (different shapes of) the wheel being reinvented over the past 2 decades, my take is slightly different: each language/environment has its strengths. If you have the luxury of having a senior team that's decently versed in several environments, then you can have your cake and eat it too: for each tool, micro-service, component... use the right language for that. Then tie it all together on the network. Since the system as a whole is likely to be a network product anyways, embrace it to your advantage. Joe Armstrong wrote a good post[1] about connecting programs a few months ago, that's quite relevant. Node.js is a great environment for many microservices. Got a task to do which is 80% done in some npm module? Make a node.js service around it. Same idea for Perl & CPAN, C libs, Java tools, etc. [1] http://joearms.github.io/2016/01/28/A-Badass-Way-To-Connect-Programs-Together.html http://joearms.github.io/2016/01/28/A-Badass-Way-To-Connect-...
• encoderer 10y ago
  I've worked in three million+ loc codebases, in PHP, Python and Java. I don't share your opinion that you need static types in these circumstances. You need discipline, modularity, and most importantly you need to have been blessed with gardeners and maintainers throughout the life of a project and not just after a mess has already taken hold.
  • Klathmon 10y ago
    Damn sorry I accidentally downvoted you on mobile... I really wish HN would fix that.
  • beders 10y ago
    Did you read what I wrote? I already said that you need a disciplined team. Good luck keeping that team together for years to come. Not sure if you are disputing the fact that keeping code around is a challenge, or not.
• spion 10y ago
  The main problem with most typed languages is basically that types are nominal by default. What I want is free-form records and structural types by default, nominal types only when necessary. I get more than half of that with TypeScript (it does lack nominal types but there are ways to get around that), and honestly its the half I prefer having.
  • majewsky 10y ago
    Most serious statically-typed languages have some sort of "anything" type where you can check the actual value type at runtime using some sort of reflection. For example, the direct Golang equivalent of a Javascript object is a map[string]interface{}.
    • spion 10y ago
      I'm not looking for an `any` type, but for structural types: Go interfaces are already a basic form of that, although a bit too basic. And I hate to say it, but Go doesn't qualify as a serious statically typed language. No language without generics does.
• MBCook 10y ago
  A lot of the Node issues seems to be due to the fact that it's a very new language. Sure JS has been around for a long time but the problem domain was small and very different from what Node is trying to achieve. Couple that with some issues other languages don't have (JS's standard library is quite thin) and I'm not surprised at these issues. I felt bits of this playing with Clojure and Go when they were new. I imagine a lot of these issues will settle down in the next few years as one or two sets of conventions become de facto standards.
• mpweiher 10y ago
  > And even then, the single-most useful function in an IDE > 'Show Call Hierarchy' will never be available when > using a dynamically typed language. True when "never" = "40 years ago". Smalltalk IDEs have had features for displaying call hierarchies statically and dynamically since essentially forever. And of course, in a dynamic environment the IDE vs. program distinction doesn't matter, so if you want to really know what's going on, just insert a self halt. and check in the debugger. Smalltalk also introduced automatic refactoring, another canard of the "impossible to do in a dynamic language" variety. Really weird when "impossible in" = "invented there". Yes, we can talk about how static type information can make some of this easier, but it also makes other parts harder (and the RB guys did talk about this, so the information is out there). Please: if you want to diss JavaScript, diss JavaScript, don't say "dynamic languages". If you want to diss dynamic languages (please do!), inform yourself first.
  • beders 10y ago
    If your IDE is your runtime environment. Sure. I've started with Allegro Common Lisp, so i kinda know a thing or two about that. The success of Smalltalk then speaks for itself?
    • mpweiher 10y ago
      So much the worse if you actually knew that what you claimed was factually wrong.