I think it is worth giving some mention that on the front of static typing Rust actually is meaningfully stronger than C++, as C++ number types internally behave like a dynamic typed language, which can turn into surprises.
I've noticed quite the increase in the quality of my code after getting used to type annotations in Python and it has made my life so much easier. Super glad that a lot of the scientific Python stack nowadays has type annotations as even quick and dirty code is easier to write with constant help from type checkers. I honestly don't think anymore that having a dynamic type system is in any way beneficial, as long as the underlying type system is expressive enough.
Yup. You, the programmer, not knowing the type of your operand is always a bug. And yet, there are still parts of the Python community which still think types are "less readable".
I've heard of SciPy but not familiar enough with Python in general (other than the typing is too loose), but just as there's Typescript (oh, he mentions it!) for Javascript, I'm wondering if The Next Great Language will be named Typon.
TL;DW if you already got legacy code (most likely in C++ or one of the big languages), you're likely to keep using that language because stability and cost savings, but if you have a short script to solve a VERY specific problem, there are a bevy of other languages will make that script easier to write "for the problem". And no, there's no prescriptive design for the "next awesome language", just vaguely showing the spectrum of languages with their focus on maintainability for 50 minutes.
44:15 Okay, so here (presuming the viewer knows ANYTHING about these languages, and they've already been touched on in the talk, so an alert viewer doesn't have to know the first thing about programming) is the rare question where the video audience does NOT need the speaker to tell us what the live audience did, though it would be interesting if as many as one person raised their hand when asked if they wanted to work on the million lines of Perl.
I'm not familiar with the Ruby syntax sugar debate, but I felt like the answer last question missed an opportunity. Both C++ and python enable operator overloading. This results in "normal code" that behaves very differently than a programmer would expect. While there are uses for this, e.g. I'm sure there are valid mathematical cases where '+' isn't commutative, doesn't satisfy the triangle property, should it exist in a standard 'case' of a Software Engineering Language?
" I'm sure there are valid mathematical cases where '+' isn't commutative" There is a very common case: string concatenation. "doesn't satisfy the triangle property, " I'm not sure what you mean by this -- the triangle inequality is not so much about the addition operator, it's about metric spaces. There certainly exist metric spaces that don't satisfy the triangle inequality (easy example in spherical geometry: take a triangle with a vertex on the north pole and two vertices along the equator; the maximum possible length of the side along the equator is the circumference of the sphere, whereas the other two sides are each only 1 / 4th of a circumference), but by definition the codomain of the metric function is the reals with addition as usually defined.
@@isodoubIet "There certainly exist metric spaces that don't satisfy the triangle inequality" -> No. The triangle inequality is part of the definition of a metric. In te sphere case, the distance between the 2 vertices on the equator is at most _half_ the circumference, when they are diametrically opposite. When they are not, the distance is the shorter way, so it's smaller.
Software engineering is the art of trying to get programmers to work together effectively across time.
I think it is worth giving some mention that on the front of static typing Rust actually is meaningfully stronger than C++, as C++ number types internally behave like a dynamic typed language, which can turn into surprises.
I've noticed quite the increase in the quality of my code after getting used to type annotations in Python and it has made my life so much easier. Super glad that a lot of the scientific Python stack nowadays has type annotations as even quick and dirty code is easier to write with constant help from type checkers. I honestly don't think anymore that having a dynamic type system is in any way beneficial, as long as the underlying type system is expressive enough.
Yup. You, the programmer, not knowing the type of your operand is always a bug. And yet, there are still parts of the Python community which still think types are "less readable".
I've heard of SciPy but not familiar enough with Python in general (other than the typing is too loose), but just as there's Typescript (oh, he mentions it!) for Javascript, I'm wondering if The Next Great Language will be named Typon.
TL;DW if you already got legacy code (most likely in C++ or one of the big languages), you're likely to keep using that language because stability and cost savings, but if you have a short script to solve a VERY specific problem, there are a bevy of other languages will make that script easier to write "for the problem".
And no, there's no prescriptive design for the "next awesome language", just vaguely showing the spectrum of languages with their focus on maintainability for 50 minutes.
Software Engineering is the art of managing software complexity.
सुंदर विश्लेषण.
44:15 Okay, so here (presuming the viewer knows ANYTHING about these languages, and they've already been touched on in the talk, so an alert viewer doesn't have to know the first thing about programming) is the rare question where the video audience does NOT need the speaker to tell us what the live audience did, though it would be interesting if as many as one person raised their hand when asked if they wanted to work on the million lines of Perl.
I'm not familiar with the Ruby syntax sugar debate, but I felt like the answer last question missed an opportunity. Both C++ and python enable operator overloading. This results in "normal code" that behaves very differently than a programmer would expect. While there are uses for this, e.g. I'm sure there are valid mathematical cases where '+' isn't commutative, doesn't satisfy the triangle property, should it exist in a standard 'case' of a Software Engineering Language?
" I'm sure there are valid mathematical cases where '+' isn't commutative"
There is a very common case: string concatenation.
"doesn't satisfy the triangle property, "
I'm not sure what you mean by this -- the triangle inequality is not so much about the addition operator, it's about metric spaces. There certainly exist metric spaces that don't satisfy the triangle inequality (easy example in spherical geometry: take a triangle with a vertex on the north pole and two vertices along the equator; the maximum possible length of the side along the equator is the circumference of the sphere, whereas the other two sides are each only 1 / 4th of a circumference), but by definition the codomain of the metric function is the reals with addition as usually defined.
@@isodoubIet A metric without triangle inequality is not a metric. Your example of points on a globe is not a metric.
@@isodoubIet "There certainly exist metric spaces that don't satisfy the triangle inequality" -> No. The triangle inequality is part of the definition of a metric. In te sphere case, the distance between the 2 vertices on the equator is at most _half_ the circumference, when they are diametrically opposite. When they are not, the distance is the shorter way, so it's smaller.