71–80 of 135 posts
Maybe my color perception is off, but it looks like Python is considered a root language with no significant predecessors. Which doesn't seem correct - Python wasn't so novel that it introduced new programming paradigms. Also, no asterisk (modern, mature compiler & runtime) for OCaml?
Earlier quoted context omitted.
Is the language community net growing or shrinking though? A language can be very alive and still not be experiencing tremendous growth.
Lazarus/Free Pascal is another example of a language still very alive, but not growing like crazy.
What interesting opinions. Rust not being a candidate for designing a future language? But C++ being a candidate for designing a future language? Go having remarkably poor design? Ruby dying, but Python and Perl not? I would really like to have a rationale for those decisions. It would be interesting to see how you can come to this conclusions.
https://trends.google.com/trends/explore?date=today%205-y&q=...
Earlier quoted context omitted.
If PHP is included, it should be colored red ("Unlikely to influence anything in the future, due to remarkably poor design") as well... If the author already classifies Go, JavaScript, or even time-tested FORTRAN and Java into this category, it's all but fair to include PHP. On the other hand, unlike the popular beliefs, the author doesn't consider Perl to be the case here? Anyway, interesting opinion.
Seems to me that Java is likely to influence things in the future, if for no other reason than because people seem to like creating languages that run in the JVM, and the libraries (if nothing else) then influence the new language.
Anyone care to explain what template void recurseFillChildren(CurTy &E) { using PackTy = std::variant ; using TyL = std::variant_alternative_t ; static_assert(std::is_same_v ); using TyR = std::variant_alternative_t ; for (i32 j = 0; j ()); if constexpr (i + 1 (E.Children.back()); } }; does, and why it can't be translated into Rust?
struct A {vector Children; int NChildren = 2, ...};
struct B {vector Children; int NChildren = 2; ...};
struct C {vector Children; int NChildren = 2; ...};
struct D {...)
template T miniParser() { return T{}; }
struct A;
recurseFillChildren(A);
The reason you can't implement this in Rust is that Rust Generics (their "template-y" language feature) is missing a few capabilities relative to C++ templates. Namely,
1. They don't operate on numbers
2. They have no notion of collections of types
Because of this, they
1. Can't know that there is a collection of types
2. Can't extract the size of the collection of types
This comes up in numerical code, where in C++ it is easy to write e.g. geometry code that is generic in the number of spatial dimensions, but in Rust it is a pain in the ass.
Why did Haskell wane? IMO, it's partly the ecosystem. There's regular Haskell, Haskell Platform, Cabal, Stack. It ends up being an alphabet soup of possibilities, and it's not clear what is depending on what. And then there's monads, which are stumbling blocks. State is allegedly the root of all evil. But I think the argument needs to be more nuanced than that: yes, state is difficult to reason about globally, but it…
Global reasoning about state is hard, hence the assistance from borrow checker. Locally mutating local state in small function? Put a reference to vars, if you want them to be mutated, just make them mut. It's also as fast.
In a way, Rust does better job of localize/encapsulate mutation than functional/monad world.
This is profoundly untrue. Its not an opinion, its simply wrong.
Other things said about Haskell, such as "memory leaks are difficult to debug" is the type of thing you hear people repeating a lot but I experienced very little of. Pretty much every language has flaws that are a bigger issue and cost more wasted time than that.
Earlier quoted context omitted.
I would have thought that at least half of your opinions were unexpected: Go's design is at the very least controversial and considered poor by a vocal subset of the hackernews and programming community. Python is decidedly not dying... it's still the dominating game in town for ML and data science. I'm surprised anybody would posit that Python were dying. Perl definitely feels like it should be in Ruby's camp.
> Go's design is at the very least controversial and considered poor by a vocal subset of the hackernews and programming community. I'm in the camp of the rationales of Go's design being controversial. But the actual design is not bad IMO. For what Go wants to be (a modern C), it is not a bad design. But who wants a modern C? I don't. But if Go were available in the 90s, I would have jumped at the opportunity to writ…
Python will gain usecases as a meta-language as the ability to automatically wrap lower abstraction libaries improves. I see Julia eating much of Python's lunch, then python abstracting its way over julia, just because it can.
Earlier quoted context omitted.
I want this to be true, by the way. As I mention in some other comment, I think Python is rather mediocre as an actual language for building software. Its appeal cannot be denied, but a majority of my peers would really like to use a language that has its tooling shit together. Python is the only language I've had to deploy that makes me understand why anybody would want to use containers.
I love Python, and it's my first and most-used language, but I definitely agree. I want something that takes the best parts of Python, is compatible with most existing Python code, and has a much better tooling ecosystem and better options for static typing. Spending a bit of time with Rust's tooling, static analysis, and "if it compiles it's pretty likely to work" (at least way more so than with Python) definitely e…
I see a lot of users forgetting that it's an opinionated history. The author hasn't claimed to make this exhaustive. Further, it's a bit counterproductive to just point out f"Hey, what about {some_lang}?" Wikipedia has a decent resource to start, if you'd care to take a journey into computation notation history :) https://en.wikipedia.org/wiki/History_of_programming_languag... My own nitpick, to throw in the mix: The…