CA was where innovation went to die far before Broadcom. It's main business process was buying popular products, "enterprising" but mostly selling them, and then selling them off as they went out of fashion.
Agreed. But please consider my efforts to have my network team to move out of the default MTU and deploy jumbo frames.... because it's always been 1500 and we feel safer keeping it in 2024.... :(
TSV are far superior to CSV as the separator is a TAB and not commas, semicolons or other weird stuff depending on your locale. Same for single and double quotes. Only thing to be aware are tsv created by Excel with newlines embedded in text fields, which are a huge PITA for almost all parsers.
Way more distant if you consider how poor would be life on Mars.
Unless you think of it as a giant experiment to travel outside the Solar system, further down the road, when the Sun will eat up the entire solar system. In that case, though, you'll need a larger cycler with a much different shuttle for you to board/unboard it...
I don't know specifically for TI calculators, but generally speaking, online sales, bulk business purchases, etc. Products normally kept on the shelf behind counters are less likely to be in these, as well.
Given that D Go Rust etc. are all Turing complete, there's no difference on their ability to compute (perform) a function.
The only difference is how easy is, and how much cr*p you need to suffer in the process.
Yet I see here people patting themselves on the back just because they re-re-rewrote the algorithm of the day (git, computing the day of the week, etc) using all sorts of programming languages to claim they were there first.
So before anyone comments that they rewrote nginx in D, let me say that we don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
Turing-complete languages have been around for the better part of a century now, had we stopped after the first one we'd still be writing some kind of Zuse machine language. There's purpose in trying to make better languages, the goal is not to be able to compute more things (since we're fundamentally more limited by the hardware than by the software), but to compute old things more efficiently and more easily. D, Go, and Rust may all be as Turing-complete as each other, they have good ideas.
That, and the fact that Turing-completeness isn't really a useful concept in real life since we don't have infinite tapes with writing heads taped on top of them. In real life, a program will be more efficient if the language it's written in (or, specifically, the implementation/compiler of that language) is smarter, even though pretty much all languages we use today are technically Turing-complete
> Yet I see here people patting themselves on the back just because they re-re-rewrote the algorithm of the day
If you cannot re-create how do you know you understand? This is one of the best ways to learn. There is zero harm here. If you don't like it you can ignore it. :)
> Can't we focus on these please, instead of being proficient at elementary level in 40+ idioms?
No, we are not in an insect colony to specialize in things.
> We don't need D or another language on top of all others we have, and that we have plenty of problems for which there's NO solution to.
Why did we build cars when we have horses?
--------
Anyhow, it is hackernews, we do things we learn, we reinvent the wheel because we can, and we are better for it.
Taking that argument to its logical extreme, why should any time spent on any of those (possibly unsolvable) problems be done in anything other than pure machine language, since that is also Turing complete?
In other words you’re severely underestimating just how much gains in easiness and reductions in suffering can contribute towards (eventually) solving the solvable subset of those problems… never mind just how significant some of those quality of life improvements can be between existing languages (and completely ignoring the potential scope of improvements not yet found in extant languages).
What if the solution to [insert sufficiently pernicious problem here] simply cannot be expressed in a human-useable fashion in a merely Turing-complete language? Having just the ability to compute a solution doesn’t mean you have the ability to understand (much less use or build atop) a solution.
So it's over 20 years old yet nobody knows it exists. Doesn't sound very promising. The first time I heard of it was someone who uses it frequently complaining about too many breaking changes in minor updates.
So it's unknown and unreliable. Who gives a crap if it has elegant syntax, it's just another way to write the same stuff. The examples from the article can be done in JS, python, java, c# almost exactly the same way. Slightly different syntax.
I don’t think it’s fair to knock a language on rate of popularity, unless your point is community adoption.
That being said, I agree with everything else you said lol.
All the “elegance” in the article just reminded me of what you can achieve using Linq, or pythons list comprehension (which I personally don’t care for).
I used to get excited about one-liners, but if that’s what elegance is, elegance is not important to me. Are you gaining efficiency or playing code golf?
If there’s anything dev jobs have taught me it’s that readability is whats most important. You can keep your fancy lambdas etc.
Those things have their place but it’s not a crime to write a for loop with local variables.
Unless what you’re doing is as simple as a single statement, a mapping or printing something, One liner loops are not as productive or efficient. when you have multiple statements, you’re often just calling multiple loops. And don’t forget the extra time you have to spend to get the damn thing to work, as opposed to a classic for loop.
I think popularity implies usefulness to a degree, but I don't disagree that it might be unfair.
As for the functional approach to collection operations, I personally like it a lot. When I used Java, I used streams a lot, now that I primarily use C# I use LINQ a lot. I think in a lot of cases the syntax is more expressive and hence more readable than loops, but both have their place and both can be used badly.
Often times you can write a simple statement that does a lot of work and is very clear to the reader, assuming they are familiar with the API/paradigm. Equivalent loop implementations can be significantly more verbose which generally reduces readability. Other times a simple task can require a very convoluted functional approach whereas a loop implementation would be fairly straight forward.
As with everything there are pros and cons, they both have their niche but personally I think I use the functional approach more than I use loops these days.
Here at least no one sues the government over free tax filing though...
reply