I feel like chat interfaces have terrible discoverability. You can ask for anything but you have no idea what the system can actually do. In the menu system the options were all spelled out - that's what discoverability means to me. If you spend enough time going through the menus and dialogs you will find all the options, and in a well-designed interface you might notice a function you didn't know about near the one you're using now.
What chat interfaces have over CLIs is good robustness. You can word your request in lots of different ways and get a useful answer.
For quick lookups, I usually use pydoc[1], which displays roughly the same help string but without having to go into the repl. I think there are several *doc functions like this. Off the top of my head I can think of texdoc (which usually just opens the pdf of the package documentation) and perldoc.
pydoc -b is also very useful as a standard lib reference when you're not connected to the internet and you can live with the quite interesting default color scheme.
It is not useless noise for something like `help(math.sin)`. The signature displayed by help is `sin(x, /)`, which tells you that `sin(x=1)` will fail. If the signature had just been `sin(x)` then `sin(x=1)` would work.
help() should not have to re-teach you the syntax of the language every time you look up an individual help topic, though. Even though this "/" stuff is uncommonly used, it seems like it should have its own help topic. Otherwise, this means that help() has to re-explain every piece of syntax that might be considered "uncommonly used", which is kind of hard to draw a line for.
Table sugar is 50% glucose and 50% fructose; the most common form of high fructose corn syrup contains 45% glucose and 55% fructose. The article you linked just talks about the dangers of a diet high in fructose at all. The parent you replied to was talking about why HFCS was seen as more damaging than table sugar.
You can also use the `say` command, which can produce an audio file that you can load into a music player app, which might be more useful since it can remember your place. https://ss64.com/mac/say.html
I have the opposite experience all the time, perhaps because I've spent a lot of time with early-career programmers. I recognise a problem and say "oh, that's a maximum flow problem", then formulate and solve it in a few lines and they are amazed in similar ways as Penn describes. They're like "how do you know all these things"? And it's just like the buried cards. I've taken all this time to read books on algorithms and solve Advent of code and so on, so my whole mind is filled with these buried cards.
Compare yourself to a person with no experience in software engineering at all and you will quickly understand how many you have, too.
Tell that to Richard Hamming: "Instead of attacking isolated problems, I made the resolution that I would never again solve an isolated problem except as characteristic of a class." [1]
I have seen this "premature abstraction" warning creep through our discourse lately, but I don't clearly understand it. I feel like I'm making calls all the time about when to introduce functions or classes that will save you time or effort in the future without forcing yourself to see the repetition before you do. Not only that but Hamming's advice has rung true in my career. Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too.
> Solving the general problem is often easier than solving a specific case and can be re-used for later instances, too.
You and the other person are both correct. What you're saying makes sense and it is what everybody is trained to do. However, it leads to a lot of useless code exactly because you're applying an abstraction that is used only once. That's why most codebases are bloated and have a huge number of dependencies.
To your point, we use abstractions all the damn time. They're everywhere. Even programming languages are an abstraction (especially high level ones). You and I, and everybody else here doesn't pick a cylinder and a block to write to and tell the hard drive to move it's arm into place and record the magnetic data, no we all talk about inserting a row into the DB.
Abstractions are essential to productivity or you'll never get out of the "make it from scratch" trap
Yes, but there is a line to be drawn somewhere. Filesystems are sufficiently advanced such that there’s no meaningful gains to be had from manually allocating CHS for data, and they provide housekeeping. C abstracts a lot of architecture-specific information away, but still requires that you understand a modicum of memory management; if you understand it (and cache line access) well, you can get even more performance. Python abstracts that away as well, and gives you a huge standard library to accomplish many common tasks with ease.
You can quickly make a prototype in Python, but it won’t be as performant as C. You can spend time profiling it and moving computationally-heavy parts into C extensions (I do this for fun and learning), but you’ll likely spend more time and get worse results than if you just rewrote it.
Docker is an abstraction over already-existing technology like cgroups. It provides an easy-to-understand model, and a common language. This is quite valuable, but it does allow one to not know about what it’s hiding, which is problematic when troubleshooting – for example, naïvely assuming that querying /proc in a container shows the CPU resources allocated to the container, rather than the host.
That’s how I view abstractions. They can be incredibly useful, but they usually have trade-offs, and those should always be considered. Most importantly, you should at a minimum be aware of what you’re giving up by using them, even if you don’t fully understand it.
I drive a car that doesn't have a backup camera and I wouldn't pay more for a car with a backup camera. I've never felt like I need it. I guess this is just how these augmentations work. By the time you've invested the time to learn the skill, you don't need the augmentation anymore. So you're left a bit puzzled by people who do. The people who use augmentations, or rely on them, have a more clear differential view. They compare their augmented ability with their non-augmented ability and it's very different.
I still have most of the python standard library and many of the interfaces I use often in my brain, so autocomplete saves me almost no time. I can type working code into notepad about as fast as I can type it in VS code.
Cars without backup camera tend to have good mirrors (exceptions exist).
Once you put the camera there by default, the designers/engineers gets many extra degrees of freedom since they aren't constrained by visibility requirements. Those degrees of freedom are certain to be exercised! On the total this is probably probably a good thing, but it sucks when the rear camera(s) are covered with snow or grime.
I don't think that System Dynamics modelling tools offer the depth of control over the governing equations that Modelica has. In addition, Modelica has a nice standard library with many physical components that you can link together to form a system.
In short, Modelica is better for simulation well-specified physical systems. System Dynamics is good for simulating the approximate behaviour of larger, often poorly understood systems.
The big point that the article is trying to make is bookended by these quotes: "... there's a standard, things ought to be simple. So you could, theoretically and perhaps even practically, use non-Microsoft software to get the job done!". "... it[LibreOffice] stubbornly refused to that, for ideological reasons."
This feels at odds with my experience of the LibreOffice community and maintainers in general, and also appears to misunderstand the detail of the OOXML standard. I think the blockers to full pixel-level replication of Office documents have more to do with the sheer complexity of the formats involved and the obscure way some of the features are described, which AFAIK often involves just saying "do this the way Word does it" instead of describing the behaviour in a completely implementation agnostic way. As a Mac user, I am very familiar with the minor differences in rendering between Mac and Windows version of Office 365. Most people will know there are differences in rendering between the web versions and the desktop versions, too. And these implementations were written by the same organisation with people who presumably had access not only to the specification but also the actual source code and libraries that were used for the "primary" Windows implementation.
For me to agree with this article's premise, I'd need to see an example of even one implementation of OOXML support that meets the author's standards.
What chat interfaces have over CLIs is good robustness. You can word your request in lots of different ways and get a useful answer.