7 ms·

Duly noted the desire of Hack to have more "typing". It seems that as soon as projects growth beyond a certain size, everybody starts wanting to add that. I wo

by dsign 8y ago

Duly noted the desire of Hack to have more "typing". It seems that as soon as projects growth beyond a certain size, everybody starts wanting to add that. I wonder what would be the optimal lifecycle for long projects. Obviously, "start with dynamic language X until you reach 10^n lines of code, then fork X and add types to it" doesn't work for smaller companies :-(

vnorilo 8y ago
A similar strategy on a smaller scale could be gradual typing, for example Typescript. For me personally, clojure + spec seems very inviting.
- wpietri 8y ago
  Yeah, I'm really excited to see people exploring gradual typing. Like dsign, I've noticed that I really like flexible languages like Ruby and Python for early work, but once something is big enough, I start to miss the things heavier languages give. I'm sure it will take us a decade to work it out, but it'll be fun getting there.
- nickserv 8y ago
  Indeed, this seems to be the best way for a small code base that gradually grows in scope and criticality. It allows rapid development early on and better stability later in the project. I'm really glad that Python is making good progress on this front.
exacube 8y ago
i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome. as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it
- jacquesm 8y ago
  Yep. A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. The reason is simple: typing functions as guard rails and guard rails are what keep you safe on the road when you are driving for 1000's of km. They have no function if you just putter about town at low speed. High line count projects almost always gravitate towards languages with such safeguards built in because otherwise the accumulation of subtle errors leads to too many runtime issues, and typing takes care of whole classes of bugs. IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferred, ditto for any mechanism that forces a program to end when an undefined situation is detected, the closer to the root cause the better.
  - wting 8y ago
    >A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. I disagree. I work(ed) at two of the more famous Python shops: Yelp and Reddit. These companies have many millions lines of Python code combined. Also FB was mostly a PHP shop until they started Hack in 2014, 2 years after they IPO'ed. Testing and monitoring can be used to combat type errors. Runtime type errors still happen occasionally, but honestly these are some of the easiest bugs to squash. I think you might be conflating static typing with strong typing when you infer that Python has "lack of typing." Python has a dynamic, but strong type system. I've coded professionally in many other languages (C, Java, Rust). I think C and Java have the worst ROI when it comes to type systems. In my opinion if you're going to use a type system on a new project today, then use something that provides stronger guarantees like Rust or TypeScript (and lowers the burden by inferring or deducting many types). Python isn't perfect, but it's still the first tool I reach for anything web, ops or data science related.
    - jacquesm 8y ago
      And bricks will fly if you add enough engine to them. It's all a matter of resources and what is the optimal path. That FB was a success even though it was built in PHP is not a testimony for PHP, it is a testimony for the engineers at Facebook who were able to pull that off despite PHPs obvious shortcomings. The fact that they built their own in-house compiler for the language speaks volumes in this respect. Yelp and Reddit also have above average resources to throw at the problems they try to solve. Python is the first tool of choice for quick solutions to immediate problems for me as well, but that does not make me blind to its obvious shortcomings.
- flyinglizard 8y ago
  Likewise. I come from a mostly C background (embedded), but now Python is especially popular in my close circles. I liked it at first, but over the past five years I grew to despise it for anything more than a single file, 300 loc program. In stark contrast, I’ve been playing around with Unity/C#/Visual Studio and my productivity with this tool stack is through the roof. There, it is rare that I create code which doesn’t fill its intended purpose the first time around. It’s all so easy, and InteliSense makes the quite verbose typing not felt. The tooling and safety is magnificent.
- aylmao 8y ago
  Types are documentation that the compiler (or interpreter) forces you to write and keep consistent, and that your editor can easily understand (:
jhabdas 8y ago
But the open source code smaller companies produce is working for the 10^n fork crowd I assure you. Choose the best tool for the job and build for throwawayability.
twblalock 8y ago
The optimal lifecycle is to start with the same language you'll finish with. You can rewrite and refactor as much as you want, but you never need to rewrite the entire thing from scratch in one shot and get it right. The funny thing is, with microservices it shouldn't really matter what language each service is written in as long as the services can talk to each other, but most companies end up using the same language for everything because it's easier to hire people who know the same language and can work on multiple projects.
- aylmao 8y ago
  Also because if you use the same language it's easier to re-use code and interface definitions.
  - Slartie 8y ago
    Yeah, going down this path usually leads to a tightly coupled, monolithic-in-practice system of "microservices" which are effectively developed and operated like the previous, monolithic system was, but with added overhead (both runtime and dev-time) on top for a layer that fakes loose coupling, with the sole actual reason for existence of this layer being that it allows people to call this abomination of an architecture "microservice-based".
    - frou_dh 8y ago
      The software architecture equivalent of Security Theater... Decoupling Theater
- wsy 8y ago
  We started with two languages on our microservice backend. It is definitely an up-front investment. But it pays off in several ways: - our service infrastructure is really language-agnostic. - our design discussions are on an abstraction level above the language level. (of course there are language-specific implementation strategy discussions, too.) - while it is a bit harder to find suitable developers, I think we attract a very valuable subset: people who are not tied to their favourite language, and don't shy away from learning new things.
Tehnix 8y ago
I feel like dynamically types programming languages had a huge hype period, and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainability is simply SO much easier when you have a good type system and the compiler can help you. I say that coming from a road starting at PHP, then moving to Python, JavaScript, Java, Haskell. Funnily enough, strongly statically typed languages are not bad at all for the early prototyping stage. In fact, I would argue that they are much better, but you have to switch your approach from slapping some functions out, to instead slapping out some ADTs, that form the basis of your app. A lot of good advice for Haskell is given in this thread https://www.reddit.com/r/haskell/comments/7sr8k7/fast_prototyping_how_to_experiences/ https://www.reddit.com/r/haskell/comments/7sr8k7/fast_protot.... One important thing to note though, is that I honestly don’t think this will work well, unless the language has at least type inference and support for ADTs, newtypes (or, tagged types) and pattern matching at the minimum. Less than that, and you end up fighting the type system, instead of letting it be your help and guide.
- tarsinge 8y ago
  > and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainability Maybe because they weren't startups anymore? Honestly I don't understand the deal with type errors in simple web apps : every input is a string which is parsed into the correct type. After this, with good naming and conventions operations should be obvious, e.g. why would you try to do a mathematical operation between a customer's name and it's account balance? To me it looks like these days the hype is copying whatever big names are doing regarding maintainability without having nearly the same constraints (static typing, huge frameworks, ...).
  - maaaats 8y ago
    > why would you try to do a mathematical operation between a customer's name and it's account balance that's a straw man to js typing, and never a problem in practice. What's more often happening, is that you change the structure of some object in your store somewhere, that's passed around a lot. And you forget to update the usage one of those places and stuff break runtime.
xixixao 8y ago
I think this might be a historical accident. What typed language could ppl use? Java, C++ mostly? They’re (for me) both a horrible mess. I think ppl will start using these “new” typed languages from get go: TypeScript (or Flow+JS), Hack, there’s likely more space for these. A high level, both functional and imperative, expressively-typed with type-inference language is going to dominate mid-term. Or still put differently, everyone’s learning from Haskell while not using Haskell.
chx 8y ago
But PHP today is a typed language. One of the new features of PHP 7.1 are Nullable Return Types http://php.net/manual/en/migration71.new-features.php http://php.net/manual/en/migration71.new-features.php
- k__ 8y ago
  How does it compare to TypeScript? I met a few PHP devs who were hating on JS, because PHP was mature now and had static typing, etc.
Moru 8y ago
I think this goes for a lot of problems in society, not just programming. We fix this and that until it's too complex to overview, then we virtualize or put a black box over it. When that doesn't work any more, we rewrite from scratch, discovering the same bugs and problems we had the first time around. Recent xkcd visualization: https://xkcd.com/2044/ https://xkcd.com/2044/
jillesvangurp 8y ago
Type systems have improved greatly in the last decades. There are now many statically typed languages that have type inferrence, generics, and other goodies. Likewise many dynamically typed languages have added support for type annotations (typescript, python, and now apparently php). The resulting code is more or less comparable in terms of verbosity and readability. IMHO the minor overhead of documenting your types is well worth the improved readability and resilience against whole categories of bugs that should not be allowed to exist in any software system. There are very few good reasons to not want that. The trend seems in any case for people to have tools in their pipeline that transpile and verify code. E.g. most javascript code gets shipped in minified form. If you are doing that, you might as well run a transpiler, some sanity checks like linters, code analyzers and type checkers. Many people do exactly that. Those type of tools benefit a lot from having more typing information available. Hence the popularity of things like typescript and recent additions to ecmascript of things like classes. Once you have that, the step to a full fledged statically typed languages is the logical next step. It seems the hack people have reached that point.

by dsign 8y ago

vnorilo 8y ago

A similar strategy on a smaller scale could be gradual typing, for example Typescript. For me personally, clojure + spec seems very inviting.

wpietri 8y ago
Yeah, I'm really excited to see people exploring gradual typing. Like dsign, I've noticed that I really like flexible languages like Ruby and Python for early work, but once something is big enough, I start to miss the things heavier languages give. I'm sure it will take us a decade to work it out, but it'll be fun getting there.
nickserv 8y ago
Indeed, this seems to be the best way for a small code base that gradually grows in scope and criticality. It allows rapid development early on and better stability later in the project. I'm really glad that Python is making good progress on this front.

exacube 8y ago

i personally started to find dynamically/optionally typed languages troublesome to read -- i have to do type deduction in my head, which just feel burdensome. as simple and easy as python feels without static typing, a handful of files of python is my tolerance level before i start to hate it

jacquesm 8y ago
Yep. A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. The reason is simple: typing functions as guard rails and guard rails are what keep you safe on the road when you are driving for 1000's of km. They have no function if you just putter about town at low speed. High line count projects almost always gravitate towards languages with such safeguards built in because otherwise the accumulation of subtle errors leads to too many runtime issues, and typing takes care of whole classes of bugs. IMO any mechanism that shifts that time of bug catching to development rather than operations should be preferred, ditto for any mechanism that forces a program to end when an undefined situation is detected, the closer to the root cause the better.
- wting 8y ago
  >A lack of typing puts an upper bound on the complexity of the code that effectively limits the line-count and relegates the language to 'glue' status. I disagree. I work(ed) at two of the more famous Python shops: Yelp and Reddit. These companies have many millions lines of Python code combined. Also FB was mostly a PHP shop until they started Hack in 2014, 2 years after they IPO'ed. Testing and monitoring can be used to combat type errors. Runtime type errors still happen occasionally, but honestly these are some of the easiest bugs to squash. I think you might be conflating static typing with strong typing when you infer that Python has "lack of typing." Python has a dynamic, but strong type system. I've coded professionally in many other languages (C, Java, Rust). I think C and Java have the worst ROI when it comes to type systems. In my opinion if you're going to use a type system on a new project today, then use something that provides stronger guarantees like Rust or TypeScript (and lowers the burden by inferring or deducting many types). Python isn't perfect, but it's still the first tool I reach for anything web, ops or data science related.
  - jacquesm 8y ago
    And bricks will fly if you add enough engine to them. It's all a matter of resources and what is the optimal path. That FB was a success even though it was built in PHP is not a testimony for PHP, it is a testimony for the engineers at Facebook who were able to pull that off despite PHPs obvious shortcomings. The fact that they built their own in-house compiler for the language speaks volumes in this respect. Yelp and Reddit also have above average resources to throw at the problems they try to solve. Python is the first tool of choice for quick solutions to immediate problems for me as well, but that does not make me blind to its obvious shortcomings.
flyinglizard 8y ago
Likewise. I come from a mostly C background (embedded), but now Python is especially popular in my close circles. I liked it at first, but over the past five years I grew to despise it for anything more than a single file, 300 loc program. In stark contrast, I’ve been playing around with Unity/C#/Visual Studio and my productivity with this tool stack is through the roof. There, it is rare that I create code which doesn’t fill its intended purpose the first time around. It’s all so easy, and InteliSense makes the quite verbose typing not felt. The tooling and safety is magnificent.
aylmao 8y ago
Types are documentation that the compiler (or interpreter) forces you to write and keep consistent, and that your editor can easily understand (:

jhabdas 8y ago

But the open source code smaller companies produce is working for the 10^n fork crowd I assure you. Choose the best tool for the job and build for throwawayability.

twblalock 8y ago

The optimal lifecycle is to start with the same language you'll finish with. You can rewrite and refactor as much as you want, but you never need to rewrite the entire thing from scratch in one shot and get it right. The funny thing is, with microservices it shouldn't really matter what language each service is written in as long as the services can talk to each other, but most companies end up using the same language for everything because it's easier to hire people who know the same language and can work on multiple projects.

aylmao 8y ago
Also because if you use the same language it's easier to re-use code and interface definitions.
- Slartie 8y ago
  Yeah, going down this path usually leads to a tightly coupled, monolithic-in-practice system of "microservices" which are effectively developed and operated like the previous, monolithic system was, but with added overhead (both runtime and dev-time) on top for a layer that fakes loose coupling, with the sole actual reason for existence of this layer being that it allows people to call this abomination of an architecture "microservice-based".
  - frou_dh 8y ago
    The software architecture equivalent of Security Theater... Decoupling Theater
wsy 8y ago
We started with two languages on our microservice backend. It is definitely an up-front investment. But it pays off in several ways: - our service infrastructure is really language-agnostic. - our design discussions are on an abstraction level above the language level. (of course there are language-specific implementation strategy discussions, too.) - while it is a bit harder to find suitable developers, I think we attract a very valuable subset: people who are not tied to their favourite language, and don't shy away from learning new things.

Tehnix 8y ago

I feel like dynamically types programming languages had a huge hype period, and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainability is simply SO much easier when you have a good type system and the compiler can help you. I say that coming from a road starting at PHP, then moving to Python, JavaScript, Java, Haskell. Funnily enough, strongly statically typed languages are not bad at all for the early prototyping stage. In fact, I would argue that they are much better, but you have to switch your approach from slapping some functions out, to instead slapping out some ADTs, that form the basis of your app. A lot of good advice for Haskell is given in this thread https://www.reddit.com/r/haskell/comments/7sr8k7/fast_prototyping_how_to_experiences/ https://www.reddit.com/r/haskell/comments/7sr8k7/fast_protot.... One important thing to note though, is that I honestly don’t think this will work well, unless the language has at least type inference and support for ADTs, newtypes (or, tagged types) and pattern matching at the minimum. Less than that, and you end up fighting the type system, instead of letting it be your help and guide.

tarsinge 8y ago
> and then all the startups we saw write in their dynamic languages later ended up adding types, because maintainability Maybe because they weren't startups anymore? Honestly I don't understand the deal with type errors in simple web apps : every input is a string which is parsed into the correct type. After this, with good naming and conventions operations should be obvious, e.g. why would you try to do a mathematical operation between a customer's name and it's account balance? To me it looks like these days the hype is copying whatever big names are doing regarding maintainability without having nearly the same constraints (static typing, huge frameworks, ...).
- maaaats 8y ago
  > why would you try to do a mathematical operation between a customer's name and it's account balance that's a straw man to js typing, and never a problem in practice. What's more often happening, is that you change the structure of some object in your store somewhere, that's passed around a lot. And you forget to update the usage one of those places and stuff break runtime.

xixixao 8y ago

I think this might be a historical accident. What typed language could ppl use? Java, C++ mostly? They’re (for me) both a horrible mess. I think ppl will start using these “new” typed languages from get go: TypeScript (or Flow+JS), Hack, there’s likely more space for these. A high level, both functional and imperative, expressively-typed with type-inference language is going to dominate mid-term. Or still put differently, everyone’s learning from Haskell while not using Haskell.

chx 8y ago

But PHP today is a typed language. One of the new features of PHP 7.1 are Nullable Return Types http://php.net/manual/en/migration71.new-features.php http://php.net/manual/en/migration71.new-features.php

k__ 8y ago
How does it compare to TypeScript? I met a few PHP devs who were hating on JS, because PHP was mature now and had static typing, etc.

Moru 8y ago

I think this goes for a lot of problems in society, not just programming. We fix this and that until it's too complex to overview, then we virtualize or put a black box over it. When that doesn't work any more, we rewrite from scratch, discovering the same bugs and problems we had the first time around. Recent xkcd visualization: https://xkcd.com/2044/ https://xkcd.com/2044/

jillesvangurp 8y ago

Type systems have improved greatly in the last decades. There are now many statically typed languages that have type inferrence, generics, and other goodies. Likewise many dynamically typed languages have added support for type annotations (typescript, python, and now apparently php). The resulting code is more or less comparable in terms of verbosity and readability. IMHO the minor overhead of documenting your types is well worth the improved readability and resilience against whole categories of bugs that should not be allowed to exist in any software system. There are very few good reasons to not want that. The trend seems in any case for people to have tools in their pipeline that transpile and verify code. E.g. most javascript code gets shipped in minified form. If you are doing that, you might as well run a transpiler, some sanity checks like linters, code analyzers and type checkers. Many people do exactly that. Those type of tools benefit a lot from having more typing information available. Hence the popularity of things like typescript and recent additions to ecmascript of things like classes. Once you have that, the step to a full fledged statically typed languages is the logical next step. It seems the hack people have reached that point.