3 ms·

> I think that says more about your particular mental model of programming than about programming in general. Well, I originally started programming only using

> I think that says more about your particular mental model of programming than about programming in general. Well, I originally started programming only using dynamic types. Then I moved to typed languages, and I could avoid whole categories of errors. I don't see it as dogma, I think typed languages are just qualitatively better at creating software. I also think this is starting to become industry experience, as efforts like Typescript, and the incremental additions to PHP's type-system show.

DerArzt 5y ago
I started on the other end (my first language was C89) and I am with you on types. Just being able to read a plaintext file and know what type every variable and parameter is just makes reading the code easier to me. My primary language is python at the moment, and I don't think I could continue without the type annotations that you can add in coupled with mypy (a static type checker that you can run on the cli as part of a build). Every time I see a regular Map with nested maps, I get a little annoyed.
chefandy 5y ago
Categorically better for everything and not categorically better for everything you write? How about for the type of task PHP is often used for? A nearly default CRUD web app w/loads of fields and tables? Rapid prototyping? How about a bunch of simple, standalone interface interactions in JS? The extra grammar won't provide much architectural or conceptual clarity in those super common coding tasks because they're already dead simple, or in the case of the rapid prototype, don't need to be durable. Most data transformation— e.g. from the database into hashes— is taken care of by worn-smooth libraries that won't likely cock things up. For these tasks, front-loading complexity for little subsequent benefit is a questionable choice. Maybe you're so used to working with types that you're just as fast,time isn't a factor? Great. If you're not, or another developer you're working with isn't, and time is tight, it's probably a bad choice. What many of these systems are starting to offer is the option of adding type hinting which is exactly what they should be doing. Python's type hints have been great in a new nontrivial project I'm putting together with multiple developers. If I had to use them for every bit of disposable utility script I write and every little prototype proof-of-concept I stand up then I'd be much less productive. I reckon skipping situation-specific cost/benefit analysis before asserting something is always better is definitely dogma. ¯\_(ツ)_/¯
- heurisko 5y ago
  > Categorically better for everything and not categorically better for everything you write? For everything. As I mentioned, I started out using dynamically typed languages. I don't agree with your idea that types somehow make it harder to develop things quickly--even the throwaway things. With types I get to grips with a new API quickly via autodiscoverability, and types provide guard-rails to know I'm using the API properly. With types, I can avoid whole categories of errors, as even the "simple" things like, for example, processing a CSV file can mess up, when someone has accidentally entered a date instead of an ID and that ends up failing for the user. It's not dogma to have an opinion that types provide a qualitatively better programming experience all around.
  - chefandy 5y ago
    Of course, you and I both can assemble thousands of tasks for which types are better suited. They would probably comprise the overwhelming majority of a random sampling of everyday coding tasks for professional developers. Having an opinion about what works best for you certainly isn't dogma— but deciding that your perspective is better for everyone else, too, regardless of the person, their needs, and the circumstances, is unambiguously dogmatic. Many coders will never touch the complexity of most full-time developers' simplest code, and they deserve tools that meet their needs, too. How much future burden will explicit type declaration relieve for an indy self-taught web designer taking strings and floats from a database through an ORM and putting them into a for loop for a web-based coffee shop menu hosted on WordPress? I'd say none. Considering that WordPress runs 37% of websites and 62% of CMSs, I'd argue that there's plenty of room for blunt instruments to do blunt work. Insisting people jump through the types hoop for posterity is not reasonable. As a long-time developer turned designer, I'm confident that using a "pack" layout strategy in many GUI libraries will consistently produce worse results than properly assembling a quick grid layout. I have my collaborators avoid it because using it == guaranteed re-write... but there's a lot of selection bias there. If teams involve someone like me, that probably means usability is paramount. As crucial as usability is, sometimes speed, convenience, and not needing barely-related expertise is more important. A developer making a dialog on a small internal utility should probably use pack even if I wouldn't. I have the patterns, organization, and syntax in my head to pull simple grid-based layouts faster than they will use 'pack.' For them, it's a bit of mental overhead for an already irritating task with no real payoff. Saying that languages shouldn't even make pack available to developers would be plainly unreasonable. Even in the tasks you cited— I was a developer in a large library with a ton of older electronic assets. I processed significant amounts of CSV and other messy text files in many dozens of projects using everything from C, shell scripts, and Perl in the earlier days to Python, Elixir, and JS in the latter. I can count how often difficult-to-pin-down data type ambiguity burned me using zero fingers. I guarantee you having to futz around with types rather than throwing in an instance check or the like would have reduced my efficiency. If I had finicky or complex or relational data that needed to maintain integrity through a nontrivial pipeline, then I wouldn't think twice about implementing them. In general, asserting that your way of doing something is universally better than other common ways of doing something is almost guaranteed to be dogmatic. For it not to be, you must provide a universally applicable truth that trumps individual use cases and people's preferences. "It avoids entire categories of bugs, near their source" doesn't work for people who will likely never encounter those categories of bugs. Insisting others are wrong for not agreeing with the accepted best practices of people who do regular professional dev work is absolutely dogmatic.

DerArzt 5y ago

I started on the other end (my first language was C89) and I am with you on types. Just being able to read a plaintext file and know what type every variable and parameter is just makes reading the code easier to me. My primary language is python at the moment, and I don't think I could continue without the type annotations that you can add in coupled with mypy (a static type checker that you can run on the cli as part of a build). Every time I see a regular Map with nested maps, I get a little annoyed.

chefandy 5y ago

Categorically better for everything and not categorically better for everything you write? How about for the type of task PHP is often used for? A nearly default CRUD web app w/loads of fields and tables? Rapid prototyping? How about a bunch of simple, standalone interface interactions in JS? The extra grammar won't provide much architectural or conceptual clarity in those super common coding tasks because they're already dead simple, or in the case of the rapid prototype, don't need to be durable. Most data transformation— e.g. from the database into hashes— is taken care of by worn-smooth libraries that won't likely cock things up. For these tasks, front-loading complexity for little subsequent benefit is a questionable choice. Maybe you're so used to working with types that you're just as fast,time isn't a factor? Great. If you're not, or another developer you're working with isn't, and time is tight, it's probably a bad choice. What many of these systems are starting to offer is the option of adding type hinting which is exactly what they should be doing. Python's type hints have been great in a new nontrivial project I'm putting together with multiple developers. If I had to use them for every bit of disposable utility script I write and every little prototype proof-of-concept I stand up then I'd be much less productive. I reckon skipping situation-specific cost/benefit analysis before asserting something is always better is definitely dogma. ¯\_(ツ)_/¯

heurisko 5y ago
> Categorically better for everything and not categorically better for everything you write? For everything. As I mentioned, I started out using dynamically typed languages. I don't agree with your idea that types somehow make it harder to develop things quickly--even the throwaway things. With types I get to grips with a new API quickly via autodiscoverability, and types provide guard-rails to know I'm using the API properly. With types, I can avoid whole categories of errors, as even the "simple" things like, for example, processing a CSV file can mess up, when someone has accidentally entered a date instead of an ID and that ends up failing for the user. It's not dogma to have an opinion that types provide a qualitatively better programming experience all around.
- chefandy 5y ago
  Of course, you and I both can assemble thousands of tasks for which types are better suited. They would probably comprise the overwhelming majority of a random sampling of everyday coding tasks for professional developers. Having an opinion about what works best for you certainly isn't dogma— but deciding that your perspective is better for everyone else, too, regardless of the person, their needs, and the circumstances, is unambiguously dogmatic. Many coders will never touch the complexity of most full-time developers' simplest code, and they deserve tools that meet their needs, too. How much future burden will explicit type declaration relieve for an indy self-taught web designer taking strings and floats from a database through an ORM and putting them into a for loop for a web-based coffee shop menu hosted on WordPress? I'd say none. Considering that WordPress runs 37% of websites and 62% of CMSs, I'd argue that there's plenty of room for blunt instruments to do blunt work. Insisting people jump through the types hoop for posterity is not reasonable. As a long-time developer turned designer, I'm confident that using a "pack" layout strategy in many GUI libraries will consistently produce worse results than properly assembling a quick grid layout. I have my collaborators avoid it because using it == guaranteed re-write... but there's a lot of selection bias there. If teams involve someone like me, that probably means usability is paramount. As crucial as usability is, sometimes speed, convenience, and not needing barely-related expertise is more important. A developer making a dialog on a small internal utility should probably use pack even if I wouldn't. I have the patterns, organization, and syntax in my head to pull simple grid-based layouts faster than they will use 'pack.' For them, it's a bit of mental overhead for an already irritating task with no real payoff. Saying that languages shouldn't even make pack available to developers would be plainly unreasonable. Even in the tasks you cited— I was a developer in a large library with a ton of older electronic assets. I processed significant amounts of CSV and other messy text files in many dozens of projects using everything from C, shell scripts, and Perl in the earlier days to Python, Elixir, and JS in the latter. I can count how often difficult-to-pin-down data type ambiguity burned me using zero fingers. I guarantee you having to futz around with types rather than throwing in an instance check or the like would have reduced my efficiency. If I had finicky or complex or relational data that needed to maintain integrity through a nontrivial pipeline, then I wouldn't think twice about implementing them. In general, asserting that your way of doing something is universally better than other common ways of doing something is almost guaranteed to be dogmatic. For it not to be, you must provide a universally applicable truth that trumps individual use cases and people's preferences. "It avoids entire categories of bugs, near their source" doesn't work for people who will likely never encounter those categories of bugs. Insisting others are wrong for not agreeing with the accepted best practices of people who do regular professional dev work is absolutely dogmatic.