5 ms·

And did you build a successful software product on your own time, risking your own money?

valvar 3y ago
Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding. Good type systems increase velocity by leaving less room for error, so that you don't have to waste half your time debugging and fixing issues that could have been easily prevented. They also provide helpful structure and an IDE experience (the right values, functions, actions, etc are actually suggested for you wherever you are) that really does speed up development a lot. There's of course always a trade-off: bad type systems can get in your way with boilerplate that you have to wrangle. But I don't think that's the typical experience.
- klibertp 3y ago
  > Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding. That's not it. I disagree with the GP, but they do have a point: coding for pay, coding for fun, and coding for your own business are all markedly different. So the question whether something works or not in one of those contexts is a valid one. I disagree with conclusion, though. Successful products are written in whatever the authors know intersected with whatever will get the job done. If you're Chuck Moore and work on embedded stuff, you'll use Forth and will be hugely successful, running circles around your competitors who use C. The relative strengths of a static type system vs unityped language are more than offset by familiarity and experience of the authors. The story changes a bit when your product grows and you need to hire a larger team of people to work on it. The benefits of a static analysis become more pronounced when the codebase gets bigger. However, if you somehow luck out and get a team of highly competent people, they will use whatever mechanisms are available to make your larger codebase still tractable, even if they use Lisp, PHP, or PERL. You can bet on something that explodes (Windows Phone...) and then your product gets done in by the choice of tech. Outside of those cases, though, the tech doesn't matter that much. Whatever you do, you'll have problems. Going for a really powerful language will severely limit your choice of libraries. Going with the most common language will leave you fighting decades of accrued nonsense. Going with statically typed language (without sane macros) will lead to lots of boilerplate code and will severely limit what you can do on runtime with the code (unless you use reflection, but then you're back to untyped land). Going with unityped/untyped language will make you hunt the inter-dependencies between your modules and you'll likely become conservative with removing old code (and other forms of refactoring) as a result. Finding a right trade-off for a tech for your product is never about a single feature of that tech. It's about a complex interplay of what you have, what you think you can get, and what you want to do.
photonbeam 3y ago
This isn't the bar though, thats a ‘can I prototype something to MVP’ situation
hnlmorg 3y ago
My shell (interactive command line environment + scripting language) is written in a type safe language. It’s tens of thousands of lines of code (maybe even hundreds of thousands, I’ve not counted) and has been actively developed for the best part of a decade. I’d have completely failed at this project if it weren’t for type safety because refactoring anything that long lived and that much code would have been a nightmare.
- JonathanBeuys 3y ago
  That is not a business though, is it? So there was no risk involved like "Will I tank my future if this fails?". What I witnessed is that makers who are willing to bet on something with real consequences dislike types as they slow down the progress and therefore the chances of success.
  - DandyDev 3y ago
    Why don’t _you_ come up with examples where non-VC funded but successful businesses are doing well in part because they chose to ignore types? At this point, I’m not even sure what you are trying to prove and I’m starting to feel that whatever it is, you’re trying to prove it to yourself mostly.
  - hardware2win 3y ago
    So only business founded with your own money has risk involved? Lol!
  - hnlmorg 3y ago
    I took the comma in your comment to mean “or” rather than “and”. You’re right. It’s not a business. But I am risking my own time (you could argue that time is money :P) Your point is pretty daft though. If was relevant to self-funded startups then it would be relevant to VC funded startups and hobby projects as well. But the fact that you’re having to dismiss all these counter examples people present demonstrates that your point is wrong and you’re simply not willing to back down from your position. Plus there’s been a wealth of companies founded on .NET and Java technologies that are older than some people on here have been alive. So it’s not like examples don’t exist. You’re not just receptive to them.

Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding. Good type systems increase velocity by leaving less room for error, so that you don't have to waste half your time debugging and fixing issues that could have been easily prevented. They also provide helpful structure and an IDE experience (the right values, functions, actions, etc are actually suggested for you wherever you are) that really does speed up development a lot. There's of course always a trade-off: bad type systems can get in your way with boilerplate that you have to wrangle. But I don't think that's the typical experience.

klibertp 3y ago
> Yes, as everyone knows, you are only entitled to an opinion about software if you are also a successful business entrepreneur without external funding. That's not it. I disagree with the GP, but they do have a point: coding for pay, coding for fun, and coding for your own business are all markedly different. So the question whether something works or not in one of those contexts is a valid one. I disagree with conclusion, though. Successful products are written in whatever the authors know intersected with whatever will get the job done. If you're Chuck Moore and work on embedded stuff, you'll use Forth and will be hugely successful, running circles around your competitors who use C. The relative strengths of a static type system vs unityped language are more than offset by familiarity and experience of the authors. The story changes a bit when your product grows and you need to hire a larger team of people to work on it. The benefits of a static analysis become more pronounced when the codebase gets bigger. However, if you somehow luck out and get a team of highly competent people, they will use whatever mechanisms are available to make your larger codebase still tractable, even if they use Lisp, PHP, or PERL. You can bet on something that explodes (Windows Phone...) and then your product gets done in by the choice of tech. Outside of those cases, though, the tech doesn't matter that much. Whatever you do, you'll have problems. Going for a really powerful language will severely limit your choice of libraries. Going with the most common language will leave you fighting decades of accrued nonsense. Going with statically typed language (without sane macros) will lead to lots of boilerplate code and will severely limit what you can do on runtime with the code (unless you use reflection, but then you're back to untyped land). Going with unityped/untyped language will make you hunt the inter-dependencies between your modules and you'll likely become conservative with removing old code (and other forms of refactoring) as a result. Finding a right trade-off for a tech for your product is never about a single feature of that tech. It's about a complex interplay of what you have, what you think you can get, and what you want to do.

photonbeam 3y ago

This isn't the bar though, thats a ‘can I prototype something to MVP’ situation

hnlmorg 3y ago

My shell (interactive command line environment + scripting language) is written in a type safe language. It’s tens of thousands of lines of code (maybe even hundreds of thousands, I’ve not counted) and has been actively developed for the best part of a decade. I’d have completely failed at this project if it weren’t for type safety because refactoring anything that long lived and that much code would have been a nightmare.

JonathanBeuys 3y ago
That is not a business though, is it? So there was no risk involved like "Will I tank my future if this fails?". What I witnessed is that makers who are willing to bet on something with real consequences dislike types as they slow down the progress and therefore the chances of success.
- DandyDev 3y ago
  Why don’t _you_ come up with examples where non-VC funded but successful businesses are doing well in part because they chose to ignore types? At this point, I’m not even sure what you are trying to prove and I’m starting to feel that whatever it is, you’re trying to prove it to yourself mostly.
- hardware2win 3y ago
  So only business founded with your own money has risk involved? Lol!
- hnlmorg 3y ago
  I took the comma in your comment to mean “or” rather than “and”. You’re right. It’s not a business. But I am risking my own time (you could argue that time is money :P) Your point is pretty daft though. If was relevant to self-funded startups then it would be relevant to VC funded startups and hobby projects as well. But the fact that you’re having to dismiss all these counter examples people present demonstrates that your point is wrong and you’re simply not willing to back down from your position. Plus there’s been a wealth of companies founded on .NET and Java technologies that are older than some people on here have been alive. So it’s not like examples don’t exist. You’re not just receptive to them.