4 ms·

First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that cr

by kls 7y ago

First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. Me personally I don't see it, I have worked on some pretty big JavaScript and LISP codebases and I cannot recall a single instance where static types would have helped us. But can think of a thousand cases where we could not have produce compact, simple and elegant code for solutions to complex problems. I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. Anything beyond that is a religious war as both can be used to build large applications if people know the tool they are working with. I don't disagree with some of your other points, the way Redux is implemented is not the way I would have done it, that being said it is effective, you can build large apps with it and personally it saves me from having to maintain that concern in custom code. As I said in my other comment I prefer an event driven architecture, it is the way Eich originally designed JavaScript and the browser API and it works.

valand 7y ago
> First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. I cannot convince with words, only experience can change one's perspective. Thanks for the reminder. I admit my opinion may spark religious skirmish. I came to love javascript in 2014 when I was making an HTML5 game almost alone. Coming from beginner java and c++, JS' flexibility blew my mind. 4 years later, I came to dislike JS for big projects. Fast-paced gaming industry drives project managers to rotate new developers in and out, leading to low knowledge retention, thus bad code quality. The project was then handed to my team. Iterating was painful. Regression was everytime. Manpower need rose up fast to add feature and tests. Long story short, led a total rewrite. Initially most people objected, now most are satisfied. For me, what's missing from JS is type system. In static-typed languages, types, used correctly, often act as contracts which bind function params and return type. It helped with knowledge retention. Most frontend devs of the company now agrees that Typescript + network and storage contract hardening saved our asses. Some argue that unit tests and documenting with comment helps, they don't. Unit tests allows us to warn future bad code change, while comments are not compiled and often not read, so I limit comments usage to the most complex code only. > I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. True, but it's sometimes the circumstances rather than the developers. I still love to write simple build scripts with JS and bash, but not big projects with people coming in and out. Unfortunately, and fortunately, the priority in my work is now both growing product and people, and that's why it's important for new developers to understand the product knowledge by the code, type helps.
- kls 7y ago
  I see your perspective, I started in small teams doing flight simulator development splitting my time between C and Assembly for 3D and Lisp for AI. I don't disagree that static typing can band-aid over bad process and churn, but it is but good process can eliminate the need for it and empower a good team of knowledgeable developers the ability to outperform a larger team. I wholeheartedly agree, about unit tests and comments, I have come to find unit test to be a cargo cult, and that they may actually cost more cycles than they save in the way most orgs implement them. And comments while great are not code, they don't thrown stack traces when they are out of date. I am very good at team building and maintaining developers in my organizations for a long period of time. This helps in our preference for using dynamic and flexible languages like LISP and Javascript.
  - valand 7y ago
    > I am very good at team building and maintaining developers in my organizations for a long period of time. This helps in our preference for using dynamic and flexible languages like LISP and Javascript. That is very nice. Hope I can learn a lot from people like you.

by kls 7y ago

valand 7y ago

> First you have to convince those of us that see no little in static typing when weighed against it constraints that it is a valid development philosophy that created a clear advantage over dynamic typed languages. I cannot convince with words, only experience can change one's perspective. Thanks for the reminder. I admit my opinion may spark religious skirmish. I came to love javascript in 2014 when I was making an HTML5 game almost alone. Coming from beginner java and c++, JS' flexibility blew my mind. 4 years later, I came to dislike JS for big projects. Fast-paced gaming industry drives project managers to rotate new developers in and out, leading to low knowledge retention, thus bad code quality. The project was then handed to my team. Iterating was painful. Regression was everytime. Manpower need rose up fast to add feature and tests. Long story short, led a total rewrite. Initially most people objected, now most are satisfied. For me, what's missing from JS is type system. In static-typed languages, types, used correctly, often act as contracts which bind function params and return type. It helped with knowledge retention. Most frontend devs of the company now agrees that Typescript + network and storage contract hardening saved our asses. Some argue that unit tests and documenting with comment helps, they don't. Unit tests allows us to warn future bad code change, while comments are not compiled and often not read, so I limit comments usage to the most complex code only. > I am in the camp of static vs dynamic is a developer's aesthetics preference, both are valid ways of getting the job done, but they depend on the developers perceptions and the way they process code. True, but it's sometimes the circumstances rather than the developers. I still love to write simple build scripts with JS and bash, but not big projects with people coming in and out. Unfortunately, and fortunately, the priority in my work is now both growing product and people, and that's why it's important for new developers to understand the product knowledge by the code, type helps.

kls 7y ago
I see your perspective, I started in small teams doing flight simulator development splitting my time between C and Assembly for 3D and Lisp for AI. I don't disagree that static typing can band-aid over bad process and churn, but it is but good process can eliminate the need for it and empower a good team of knowledgeable developers the ability to outperform a larger team. I wholeheartedly agree, about unit tests and comments, I have come to find unit test to be a cargo cult, and that they may actually cost more cycles than they save in the way most orgs implement them. And comments while great are not code, they don't thrown stack traces when they are out of date. I am very good at team building and maintaining developers in my organizations for a long period of time. This helps in our preference for using dynamic and flexible languages like LISP and Javascript.
- valand 7y ago
  > I am very good at team building and maintaining developers in my organizations for a long period of time. This helps in our preference for using dynamic and flexible languages like LISP and Javascript. That is very nice. Hope I can learn a lot from people like you.