hey Jeff! long time! I've been working on some large Perl code bases for a long time now. I have a love/hate relationship with Perl and other Duck-Typed languages. I have seen many bugs over the years that a statically typed compiled language would have prevented outright that I am ready to move back to a compiled/static language. We have officially said "no more Perl" and adopted python to better allow us to find developers! However, for me, Perl->Python is a lateral move. I am hoping to find a way to move to C++ for my next big project.
Sorry that was a bit off topic. I wanted to say that Perl6/Raku seems to have taken things to a whole new level with smart match and other fuzzy features that try to "do the right thing".
Hey Hank, good to hear from you! I hear you on the "do the right thing" issue: Instead of trying to outsmart you, it would be nice if the language would just get out of your way.
Perl and C++ will always hold a special place in my heart, as you may remember that they got me through some tough (for my 20-something self) projects back at Sun. But if you have the option, go with Rust instead of C++ now. The developer experience is vastly superior: Standard build and package management, better error messages, and none of the gotchas that make C++ development so painful. If you want an easier transition from Perl/Python, Go is also a great choice. (I used a bunch of Go and Rust recently, and found Rust more powerful, but Go much easier to learn.)
The last time I thought about this problem, I had an interesting idea. Start at "compile error", but allow the author to write an explicit override for `+(string, int)` that defines the alternate behavior that is desired, so that if you REALLY want it that way, it's easy for someone else to read what it's doing.
Sure, I think that's a valid option. In fact, that's how C++ works: Anybody can define their own operator+(std::string, int). Another approach is to let people define new operators, as in Haskell or Scala. One shortcoming that comes up in all of those languages is that someone reading the code doesn't immediately know the custom behavior, since it varies from one codebase to the next; so as you say, looking up the meaning ought to be easy for the reader. Operators can make lookup tough though, as they're not usually imported by name. C++ even added a special feature, Argument Dependent Lookup, specifically so you could use custom operator overloads without explicitly importing them: https://en.cppreference.com/w/cpp/language/adl
hey Jeff! long time! I've been working on some large Perl code bases for a long time now. I have a love/hate relationship with Perl and other Duck-Typed languages. I have seen many bugs over the years that a statically typed compiled language would have prevented outright that I am ready to move back to a compiled/static language. We have officially said "no more Perl" and adopted python to better allow us to find developers! However, for me, Perl->Python is a lateral move. I am hoping to find a way to move to C++ for my next big project.
Sorry that was a bit off topic. I wanted to say that Perl6/Raku seems to have taken things to a whole new level with smart match and other fuzzy features that try to "do the right thing".
Hey Hank, good to hear from you! I hear you on the "do the right thing" issue: Instead of trying to outsmart you, it would be nice if the language would just get out of your way.
Perl and C++ will always hold a special place in my heart, as you may remember that they got me through some tough (for my 20-something self) projects back at Sun. But if you have the option, go with Rust instead of C++ now. The developer experience is vastly superior: Standard build and package management, better error messages, and none of the gotchas that make C++ development so painful. If you want an easier transition from Perl/Python, Go is also a great choice. (I used a bunch of Go and Rust recently, and found Rust more powerful, but Go much easier to learn.)
The last time I thought about this problem, I had an interesting idea. Start at "compile error", but allow the author to write an explicit override for `+(string, int)` that defines the alternate behavior that is desired, so that if you REALLY want it that way, it's easy for someone else to read what it's doing.
Sure, I think that's a valid option. In fact, that's how C++ works: Anybody can define their own operator+(std::string, int). Another approach is to let people define new operators, as in Haskell or Scala. One shortcoming that comes up in all of those languages is that someone reading the code doesn't immediately know the custom behavior, since it varies from one codebase to the next; so as you say, looking up the meaning ought to be easy for the reader. Operators can make lookup tough though, as they're not usually imported by name. C++ even added a special feature, Argument Dependent Lookup, specifically so you could use custom operator overloads without explicitly importing them: https://en.cppreference.com/w/cpp/language/adl