The last paragraph captures the essence that all the PL theory arguments do not.
"Zig has a fun, subversive feel to it".
It gives you a better tool than C to apply your amazing human skills, freely, whereas both Rust and Go are fundamentally sceptical about you.
Self-aware people are mindful about what "future them" might do in various scenarios, and they plan ahead to tamp down their worse tendencies. I don't keep a raspberry cheesecake in my fridge, even though that would maximize a certain kind of freedom (the ability to eat cheesecake whenever I want). I much prefer the freedom that comes with not being tempted, as it leads to better outcomes on things I really care about.
In a sense, it is a powerful kind of freedom to choose a language that protects us from the statistically likely blunders. I prefer a higher-level kind of freedom -- one that provides peace of mind from various safety properties.
This comment is philosophical -- interpret and apply it as you see fit -- it is not intended be interpreted as saying my personal failure modes are the same as yours. (e.g. Maybe you don't mind null pointer exceptions in the grand scheme of things.)
Random anecdote: I still have a fond memory of a glorious realization in Haskell after a colleague told me "if you design your data types right, the program just falls into place".
> Random anecdote: I still have a fond memory of a glorious realization in Haskell after a colleague told me "if you design your data types right, the program just falls into place".
There's a similar quote from The Mythical Man Month [0, page 102]:
> Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they’ll be obvious.
And a somewhat related one from Linus [1]:
> I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
I would rather live in a world where I can put a raspberry cheesecake in my fridge occasionally. Because I know how to enjoy cheesecake without having to buy it every week. Not a world where when I pick the cheesecake off the shelf in the store someone says "Raspberry cheesecake! You may be one of these people who is lacking in self awareness so let me guide you. Did you know that it might be unsafe! Are you sure it's going to lead to a better outcome?"
A programming language forces a culture on everybody in the project - it's not just a personal decision like your example.
I think I see it slightly differently. Culture is complex: I would not generally use the word “force” to describe it; I would say culture influences and shapes. When I think of force I think of coercion such as law and punishment.
When looking at various programming languages, we see a combination of constraints, tradeoffs, surrounding cultures, and nudges.
For example in Rust, the unsafe capabilities are culturally discouraged unless needed. Syntax-wise it requires extra ceremony.
When it comes to our ability to write bug-free code, I feel like humans are not actually not that good at writing bug-free code. We just don't have any better way of producing software than that, and software is useful. This doesn't mean we're particularly good at it though, just that it's hard to motivate people to spend effort up front to avoid bugs when the cost of them is easy to ignore in the short term when they're not obvious. I feel like the mindset that languages that try to make them more apparent up front (which I honestly would not include Go as one of) are somehow getting in the way of us is pretty much exactly the opposite of what's needed, especially in the systems programming space (which also does not really include Go in my mind).
I for one welcome the use of type systems and PL research to guide me in expressing my programs in correct ways and telling me when I'm wrong based on solid principals. If you want to segfault for fun, there's a time and a place for that, but it's not in my production code.
And yet all that PL research couldn't stop rust from bringing cloudflare down.
And the compiler had nothing to say about it. "Carry on, thisi is perfectly fine rust code that might crash your app with a panic if left unchecked, no biggie. LGTM" - rust compiler
I'm so sick of hearing about how "Rust brought cloudflare down". No it did not. Unhandled error cases are possible in any language, and calling `unwrap` is literally the developer telling the compiler, trust me, it's not an error.
At the very least, something that brings the application down when the dev assumption fails should be called a much more dangerous word than "unwrap".
So yes, the language has failed there.
"You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.
> "You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.
The thing is that Rust's promises are more tightly scoped to very specific types of (mis)behavior. I don't believe it has ever claimed to prevent any and all types of stupidity, let alone ones that have non-stupid uses.
There is nothing suspicious or abnormal about this behavior. It is called competition. Ironically, trying to prevent this kind of behavior prevents competitiob, and is a key factor for causing monopolization
It depends... if OpenAI bought the DRAM in order to use it, then fair play to them.
If they bought the DRAM in order to stop their competitors from using it because they are falling behind, that's anticompetitive in spirit, though I'm not sure if it actually breaks any laws.
Knowingly attempting to buy or sell in quantities likely to move markets, for direct profit, is called manipulation and is most definitely illegal. this is true in physical markets commodity markets and financial markets. Not saying that this is what openAI is doing but it definitely merits an investigation.
All quantities bought or sold on the margin will move the market. Whether it moves the market is not up to the buyer or seller; it is up to other buyers and sellers who react to that transaction and adjust their expectations. This is normal market dynamics, dynamics we should want to happen because markets adjusting to movements of big players performs a social function; you and I need to know how large movenents of resources affects our livelihoods, and this is how that can happen.
There is no reason to pathologize or find suspicious these normal economic facts. Especially when it is not within the power of a big player to choose how other people react to their actions, which is all "moving markets" is. If something is suspicious and illegal about that, then it is equally suspicious that you and I seem to go along with this "market movement" by these big players and pay the new prices. Are we colluding with them? We could do with less conspiracy-minded interpretations of these things.
market economics are like newtonian mechanics. It's all so wonderful and logical and even elegant, until the dimensions expand a few orders of magnitude, and then all the rules break. Having worked on a trading floor for 20 years I know how this works. Swamping a market with huge trades is definitely considered manipulation by essentially all authorities, and indeed is a form of monopoly power, which even economic theorists will agree is undesirable. Jane Street just got a mega fine for exactly this in India, btw.
I can't get over the confident dismissal of science by hand-waving about imperfect modelling. But what I said has nothing to do with that, and is more true to the real world than an idealized perfect competition model. Pathologizing normal trading behavior like this is more the result laymen and authorities misinterpreting bad economic modelling. So I recommend you take some of your own medicine and look at the mirror. Maybe a trade affecting the market isn't so suspicious as you make it out to be, because the perfect competition model you're using to make accusations of monopoly simply doesn't make sense. Again, if there is something wrong with affecting the market, then you or I are just as liable for our consciously self-interested behavior of choosing higher-quality, lower-priced products.
That is the whole point, to make company much bigger than they actually are and shift the power back to smaller player, in this case the state and GDP.
If you compare annual revenue to GDP all of a sudden these so called maegacrop are tiny.
I'd prefer even more matplotlib-ish. Don't fix what's not broken.
A major reason why other plotting libraries don't take of is use of complicated APIs. But data analysis doesn't need Application Programming Interfaces, it needs User Interfaces.
Not sure what you mean by complicated API. The (pylab) API is a very straightforward (mostly) immediate rendering typeish interface, with a lot of convenient shortcuts for operations used a lot in data analysis.
For architecture astronauts there's also the OOP API over which the pylab API is a wrapper.
Of course there are also a lot of all sorts of declarative APIs, which are popular with people copy-pasting code from cookbooks. These become very painful very fast if you do something that's not in the cookbook.
Matplotlib does struggle with performance in some/many cases, but it has little to do with the API.
Just my personal experience from using the library for at least 7-8 years. So many things and concepts are glued onto each other, making the API so much non-intuitive whenever you try to do anything more sophisticated that isn't a 1:1 match from examples found in the cookbook. It's really a PITA and performance, I have to say this again, is really really bad. If this had been part of my daily job I would certainly try to switch to something else.
Performance for animation and (custom) interaction is a real problem. But as for performance being "really really bad", there are not many widely used plotting libraries faster than it, at least for static plotting and zoom/pan interaction.
There are indeed many ad-hoc functions, typically for commonly used cases, and they tend to cover vast majority of common use case with very simple and concise code. If you want something more custom, the underlying artist API is very flexible. But you probably know this based on the 7-8 years?
Things like subplot layouts, data point annotation and legend tweaking can be really painful. Something like a proper box/model CSS layouting would be great.
I feel like everyone has different expectations for a scientific plotting API. The tension between ease of use and expressivity is so strong that a one-size-fits-all solution is unlikely ever to exist.
I would argue that the Matplotlib syntax is horribly broken (or rather, the Matlab syntax it historically tried to emulate, and had to stick with for better or worse..)
Complaining about the inconsistencies of the matplotlib interface is pretty much beating a dead horse by now, and has been done repeatedly and in detail by others.
The problems start as soon as you try doing something more than plt.plot(), and you get your first encounter with the maddening interface differences between a single figure plot and a multi-figure plot. And then it spirals out of control from there.
There is no denying that a lot of effort was put in the library over the years, with lots of documentation and examples, but my general experience over the 15 years I've been using it is that as soon as you try doing something slightly different than the defaults, it invariably turns out to be a time-consuming, frustrating endeavour, with no guarantees that you'll get the result you want.
Sure there are some inconsistencies and legacy, but I wouldn't call that "horribly broken".
You're probably referring to plots with subplots. Those indeed have issues, although mostly not because of the API. This has somewhat improved with the constrained layout, within the old API. There's also now GridSpec for more control. And for EDA those don't really matter much. There are some annoying differences when calling Axis methods vs the global functions (e.g. xlim vs set_xlim).
Tweaking plots exactly as you want can get tricky, although for that the artist API can get you more or less anything you want. Care to share what's the library that gives you guaranteed results in no time and with no frustrations?
> You're probably referring to plots with subplots. Those indeed have issues, [..] There are some annoying differences when calling Axis methods vs the global functions [..]
When plotting is the basis of what a library does, and there are annoying differences encountered at such a very basic usage level, then it is not completely unreasonable to express some grievance about the syntax imposed to the user.. It is a frustrating user-experience to start encountering issues at such a fundamental level.
Tweaking plots, axis and layouts is tricky. Animating a plot with a bit of control is non-trivial, although I am prepared to concede that the two are different beasts.
My most recent annoyance was for something that seemed superficially easy: duplicating a left axis to a right axis, with a different label text, keeping the "original" grid and limits. Think of degree Kelvin on the left, and the equivalent in Celsius as a right axis. After more than 30 minutes of trying, I simply gave up as it was way beyond the amount of time I could justify spending on a single plot.
reply