3 ms·

For simple apps, dynamic typing may be OK, but I'm always writing complex apps, and static typing just seems like a minimum required feature for any language I

For simple apps, dynamic typing may be OK, but I'm always writing complex apps, and static typing just seems like a minimum required feature for any language I want to use for complex apps. So I guess I'll stick with TypeScript or C# for writing my cross-platform apps. The ecosystems for both are much more robust anyway.

dualogy 10y ago
I think a problem is that complex apps are made with scripting languages. This nasty practice seems to have finally become widespread habit in earnest with Perl in the hey-days of CGI httpd, and then of course came along Python and JavaScript and here we are! I agree that strongly & statically typed languages allow for and indeed yield more robust ecosystems and complex apps. But scripting languages have their place, roughly at the level of bash/.sh/.bat scripts IMHO .. the issue is that as LoB apps evolve from "simple one-off experiments" and "just a quick'n'dirty prototype to see if-and-how" to "mission-critical infrastructure" there just seems to never be a good time for anyone to say "we stop here, let's transfer this to a more stringent language early on first now, better today than too late". Best would be if "scripting languages" actually had Haskell levels of type inference, even if not the rich type system, this way there wouldn't be type annotations (just like in scripting) BUT with a toggle-able "scripting-like lenience" that can be turned off to make the type-checker brutal, or initially during prototyping/scripting turned on by default to allow for ambiguous / uninferable / defer-to-runtime-and-allow-unsafe-conversions RAD-style work. With an additional middle-ground setting where it's still lenient but emits console warnings to review potentially troublesome sections. Someone should create a whole new scripting language just for that! Any takers?
- fho 10y ago
  IMHO Haskell is not a bad "scripting language", whatever that means. My current project has lots of nice, composable blocks that get compiled in a library project and I use stacks scripting feature to just glue them together. Works for me.
  - SomeCallMeTim 10y ago
    Personally, I write games a lot, and I write apps with rich UI behaviors. Both have a lot of inherent statefulness and imperative behaviors that are, in my opinion, modeled better using a a language that at least supports imperative structures. Both also benefit a lot from OO principles. I also use functional concepts, and my code also ends up with lots of nice, composable blocks, but being in a language that forces functional concepts where they don't fit is a recipe for unneeded complexity and unintuitive code. Functional isn't a silver bullet. There Is No Silver Bullet.
    - fho 10y ago
      Naa ... without wanting to get into a religious war here: Haskell actually provides an imperative "mode" (aka "do-notation"). But I agree about the silver bullet thing ... I am/was a Java developer by trade and have written my fair share of Python and C/C++ code. Haskell just clicked with me after getting over the initial hurdles and is a good fit for the work I do (which is processing about 400kEvents per second from a custom sensor).
- SomeCallMeTim 10y ago
  > I think a problem is that complex apps are made with scripting languages. This nasty practice seems to have finally become widespread habit in earnest with Perl in the hey-days of CGI httpd, and then of course came along Python and JavaScript and here we are! Exactly, though the dynamic languages like Python did reveal some serious shortcomings with the "older" languages like C++ and Java. Which is why I'm so happy using TypeScript. It gives you the ability to layer static types on a language that still offers the flexibility and concise code that are unavailable in C++ and Java.

dualogy 10y ago

I think a problem is that complex apps are made with scripting languages. This nasty practice seems to have finally become widespread habit in earnest with Perl in the hey-days of CGI httpd, and then of course came along Python and JavaScript and here we are! I agree that strongly & statically typed languages allow for and indeed yield more robust ecosystems and complex apps. But scripting languages have their place, roughly at the level of bash/.sh/.bat scripts IMHO .. the issue is that as LoB apps evolve from "simple one-off experiments" and "just a quick'n'dirty prototype to see if-and-how" to "mission-critical infrastructure" there just seems to never be a good time for anyone to say "we stop here, let's transfer this to a more stringent language early on first now, better today than too late". Best would be if "scripting languages" actually had Haskell levels of type inference, even if not the rich type system, this way there wouldn't be type annotations (just like in scripting) BUT with a toggle-able "scripting-like lenience" that can be turned off to make the type-checker brutal, or initially during prototyping/scripting turned on by default to allow for ambiguous / uninferable / defer-to-runtime-and-allow-unsafe-conversions RAD-style work. With an additional middle-ground setting where it's still lenient but emits console warnings to review potentially troublesome sections. Someone should create a whole new scripting language just for that! Any takers?

fho 10y ago
IMHO Haskell is not a bad "scripting language", whatever that means. My current project has lots of nice, composable blocks that get compiled in a library project and I use stacks scripting feature to just glue them together. Works for me.
- SomeCallMeTim 10y ago
  Personally, I write games a lot, and I write apps with rich UI behaviors. Both have a lot of inherent statefulness and imperative behaviors that are, in my opinion, modeled better using a a language that at least supports imperative structures. Both also benefit a lot from OO principles. I also use functional concepts, and my code also ends up with lots of nice, composable blocks, but being in a language that forces functional concepts where they don't fit is a recipe for unneeded complexity and unintuitive code. Functional isn't a silver bullet. There Is No Silver Bullet.
  - fho 10y ago
    Naa ... without wanting to get into a religious war here: Haskell actually provides an imperative "mode" (aka "do-notation"). But I agree about the silver bullet thing ... I am/was a Java developer by trade and have written my fair share of Python and C/C++ code. Haskell just clicked with me after getting over the initial hurdles and is a good fit for the work I do (which is processing about 400kEvents per second from a custom sensor).
SomeCallMeTim 10y ago
> I think a problem is that complex apps are made with scripting languages. This nasty practice seems to have finally become widespread habit in earnest with Perl in the hey-days of CGI httpd, and then of course came along Python and JavaScript and here we are! Exactly, though the dynamic languages like Python did reveal some serious shortcomings with the "older" languages like C++ and Java. Which is why I'm so happy using TypeScript. It gives you the ability to layer static types on a language that still offers the flexibility and concise code that are unavailable in C++ and Java.