pure-awesome

"Apps like Instagram have a standard carousel for photo albums"

Yeah, but that only applies to users who are used to Instagram. It's definitely not an INTUITIVE feature.

I've had friends and family link me to Instagram posts, and though I've learned now, for a long time they'd have to explicitly mention there were additional pictures in the post, or I'd miss them.

(I don't know if it's different in the app, but certainly in the webpage those little dots at the bottom are non-obvious to a first-time user.)

Scott Alexander recently gave a good summary & review of that book here. A _very_ interesting hypothesis:

https://slatestarcodex.com/2020/06/01/book-review-origin-of-...

Object orientation is not really about making use of structs - many (most?) functional languages also use structs; it's just a grouping of related data.

Object-orientation is about grouping together functionality and data. I.e., an object consists of both a struct, and the functions that act on that struct, known as methods.

In OO, your type additionally refers to the functions called on the data, not just on the data. E.g. you might have a car and a boat and they both only have a position and velocity as data, but the boat has a "sink" method the car doesn't.

There are also debates on what qualifies as "true" object orientation. https://stackoverflow.com/questions/250062/what-is-meant-by-...

For games programming in particular, there is a paradigm known as ECS or Entity Component System. (Depending on your view you might call this a sub-paradigm of object orientation, but I think it's much more accurately described as an alternative.) As the Wikipedia article states:

> An entity only consists of an ID and a container of components. The idea is to have no game methods embedded in the entity.

https://en.wikipedia.org/wiki/Entity_component_system

EDIT: There's also the very interesting paradigm that e.g. Julia uses known as "Multiple Dispatch". This is kind of like defining methods on objects, except that the method is defined on a collection of objects instead of a single one.

E.g., in traditional OO, you might have a vehicle#crash method. And it might take another vehicle as argument, e.g. car.crash(truck). But in multiple dispatch you define a function crash that takes in two vehicles, and then depending on the type of the vehicles given, it changes its behaviour so that crash(car, truck) is different from crash(car, car).

In a sense, the function is not thought of as belonging to either the car or the truck, but as belonging to the pair of them, so conceptually this is different to OO.

I'm not particularly familiar with the paradigm so I'm sure I'm not doing it justice, but you can read further on Wikipedia and in the Julia docs, or the given video:

https://en.wikipedia.org/wiki/Multiple_dispatch

https://docs.julialang.org/en/v1/manual/methods/index.html#M...

https://www.youtube.com/watch?v=kc9HwsxE1OY

For those wondering what I mean:

To support backwards-compatibility, Java could not simply introduce functions as first-class objects. Instead, it works like follows:

Syntax for a function `foo` which itself takes in a function called `intConcat` that takes in two ints and spits out string:

    foo(BiFunction<Integer, Integer, String> intConcat) {
        // ...
    }

Notice that I have to explicitly state "BiFunction". There is also "Function" for single-argument functions, and nothing for more arguments (there are also `Runnable`, `Consumer` and `Producer` for fewer arguments in-or-out). This is because BiFunction isn't actually a function - it's an INTERFACE! Any class that implements 'apply' and 'andThen' functions with the right signatures will satisfy it, and can be passed in. You can make your own class and Java will happily accept it into this method.

Java then just adds some nice syntactic sugar to make stuff look like functions. E.g., if you do want to define an anonymous lambda like

    (x,y) -> "" + x + y;

What happens under-the-hood is that Java defines an anonymous BiFunction class. You can assign it to a variable and do everything you would want to do with an object:

    BiFunction<Integer, Integer, String> bif = (x, y) -> "" + x + y;

I can call bif.toString() and all those other default methods defined on objects in Java. It's really not a function, it's an object holding a function:

    BiFunction<Integer, Integer, String> {

        String apply(Integer x, Integer y) {
            return "" + x + y;
        }

        // ...
    }

and if you were to go and implement your own BiFunction as above (filling in the blanks) - you could pass it around exactly the same places as your "anonymous lambda" and it would work exactly the same way because it IS the same thing.

Like I said, a very object-oriented approach to functionality.

Luckily Java 8 introduced streams and functional interfaces - the latter of which is admittedly very object-oriented way of passing around functions.

In addition to this, mark them clearly as out-of-stock - fade out the preview image and prepend [out of stock] to the item description.

I wasn't only thinking of computer simulations. The word "simulation" is very vague.

It could potentially mean one of:

- Computer Simulation

- Pen & Paper Mathematical models

- Pen & Paper narrative modelling (i.e., writing a paper about different situations and the possible contingency plans - though granted this is not usually referred to as "simulation")

- Role-playing a situation via speech

- Acting out a situation with props and physical movement / simulated limited communication

- Sending out simulated broadcasts ("this is only a test")

- Sending out false but believable broadcasts

- Infecting the public with a (hopefully less harmful) disease in order to gauge response.

I was confused what they meant by "simulation". But they basically mean like a role-playing game. Like, they acted out how they would respond in that particular situation.

This site has more info:

http://www.upmc-biosecurity.org/website/events/2001_darkwint...

http://www.upmc-biosecurity.org/website/events/2001_darkwint...

Yes.

A better name for "the speed of light" might actually be "the speed of time" or "the speed of information transfer".

It's a mathematical limit and you can derive it using pretty much anything, not just light.

As an object goes faster, it experiences time dilation, length contraction, etc. The "Speed of Light" C is basically the point at which all of these things reach either zero or infinity.

It also "just so happens" that electromagnetic waves (such as light) travel at exactly this speed in a vacuum. They travel that fast because they travel at the maximum possible speed, and that happens to be the maximum possible speed.

It's like if you always traveled at the speed limit because you didn't want to break the law, and we called it "triplesex_ speed", but really it's just the maximum speed that anyone would go if they didn't want to break the law.

Except in this case it's not just a law- it is (to the best of our knowledge) physically impossible to go faster. It's not just that we haven't seen anything go that fast- it's that going faster than that doesn't even really make sense theoretically - for example, it would result in time-travel (this has to do with the fact that the order in which events happen and the speed at which time passes is different to different observers depending on the speed at which you're traveling).

It sounds like they're using:

- "severity" as level of importance the tester assigned it when they found the bug and - "priority" as level of importance a developer assigned to it after triage.

That first piece of information is important when you need to determine which bugs to look at first for triage, but how important is it after that point? Can it not just be replaced after the developer's judgement?

In other words, could you not have a single priority field? The tester uses a heuristic to assign an initial priority (e.g., crashes are P0, cosmetic are P4). The dev uses this to prioritize which bugs to triage first, and once they've determined a new priority based on customer experience combined with app behaviour, they replace the old one.

If you really need to go back and check what the tester assigned, then I assume you can just use the "history" or "revision" feature in your bug tracking app.

Additionally, as suggested in a different comment, you can add a label for the bug's type if you feel that's important (crashing, lagging, cosmetic, etc.).

Perhaps the message here is that the app's behaviour in a vacuum is not the sole determinant of its priority. But then that should be the message, rather than claiming there is another metric which needs to be separately tracked when evaluating bugs.

That's example 6 on the list.

The previous commenter was not saying that machine learning didn't exist 10 years ago. They were saying that "many of the TOP CONTRIBUTORS TO THAT FIELD were not doing machine learning research 10 years ago."

There are also people who were doing machine learning 30 years ago and are still doing so. But there are people who were doing, say, fluid dynamics simulations 10 years ago who self-taught machine learning, and are now making significant contributions to machine learning, by transferring their knowledge of programming, optimization, calculus, etc.

Yes. Taking into account gut feelings has been a part of the rationalist community's strategy for as long as I can recall.

The rationalist community's "Rationality" is not about using cold calculation for everything. It's about not letting your human biases and motivated reasoning get in the way of finding the truth and being effective. (Whether or not the movement is successful is a bit of a debate, of course, but the core philosophy is sound).

https://www.lesswrong.com/posts/z9hfbWhRrY2Pwwrgi/summary-of...

> System 1—the intuitive system—is the older of the two and allows us to make quick, automatic judgments using shortcuts (i.e. heuristics) that are usually good most of the time, all while requiring very little of your time and attention.

> System 2—the deliberative system—is the newer of the two and allows us to do things like abstract hypothetical thinking and make models that explain unexpected events. System 2 tends to do better when you have more resources and more time and worse when there are many factors to consider and you have limited time.

...

> The main thing to take away from this System 1 and 2 split is that both systems have strengths and weaknesses, and rationality is about finding the best path—using both systems at the right times—to epistemic and instrumental rationality.

> Being “too rational” usually means you are using your System 2 brain intentionally but poorly. For example, teenagers were criticized in an article for being “too rational” because they could reason themselves into things like drugs and speeding. But this isn’t a problem with being too rational; it’s a problem with being very bad at System 2 reasoning!

I think it could potentially work!

Consider someone with little to no experience with programming trying to build a single app and planning it out and refactoring and refining it continuously, compared to constantly creating and archiving multiple toy prototypes of the same app and then considering the best among those.

(The app's size and complexity should be commensurate to a single clay pot in a ceramics course.)

It requires the students to actually try to make something of quality, sure, but only to the same degree that the students in the original (apocryphal) story did- after all, those students could easily have shown up with a pile of baked misshapen clay instead of proper pots.

Do they start them at $1'000 and let them bid down from there?

My goodness, would you look at that! Luckily the paperback is only 1% the price, so solid deal there!

I thought it's a data entry error, but no, it looks like that's the legitimate price range for the NEW hardcovers (the actual listed ones are even more!):

https://www.amazon.com/gp/offer-listing/B0007JVUSK/ref=dp_ol...

It's either a ripoff, or some sort of collector's edition original versions. Though if it were the latter, I'd have expected it to be advertised as such.

This point is made in the book "The Soul of the White Ant" by Eugène Marais, and is perhaps the primary thesis of the book.

It is a fascinating book, and I can recommend reading it, though having been published in 1925, it is possible some of the information is out-of-date.

https://www.amazon.com/Soul-White-Ant-Complete-Unabridged/dp...

"White Ant" actually refers to termites, though the same principles apply. The book was originally published in Afrikaans. According to Wikipedia:

> [The book] was plagiarised by Nobel laureate Maurice Maeterlinck, who published La Vie des Termites (translated into English as The Life of Termites or The Life of White Ants), an entomological book,[3] in what has been called "a classic example of academic plagiarism" by University of London's professor of biology, David Bignell.[4]

https://en.wikipedia.org/wiki/Eug%C3%A8ne_Marais#Theft_of_hi...

Following reference [4] led to this page which I unfortunately don't have the time to read in its entirety right now, but from a skim seems to have some interesting further information on termites:

https://web.archive.org/web/20070915005006/http://www.biolog...

I used to think that if something is done twice, it should be abstracted.

Now, I'm a bit more careful. There's a pretty famous quote by Sandi Mentz: "Duplication is far cheaper than the wrong abstraction."

https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti...

Make sure that you're picking the write way to think about the task at hand, rather than blindly following DRY.

There are times when even a single instance of a code call would be made clearer with abstraction, and there are times where having the same piece of code duplicated multiple times (or duplicated with one piece changed) is far clearer than trying to abstract it.

This Reddit Comment also has an interesting take: https://www.reddit.com/r/programming/comments/5txp5t/duplica...

> The main purpose of abstractions is not to remove or reduce duplication, and not even to make code "reusable"; it is to make semantic patterns and assumptions explicit and, if possible, first-class.

The further comments provide more discussion.

---

I agree with the rest of your comment that refactoring and code-cleanup should be done in pieces and that, as with everything, striking the right balance is key.

Ah! I understand your comment now, by

> obsession with 9-5 and whatever else it takes

You mean an obsession with "working 9-5 ALONG WITH whatever else it takes", not an obsession with "9-5" and a separate obsession with "whatever it takes".

Maybe I misunderstand your comment, but aren't "9-5" and "doing what it takes to get the job done" contradictory?

The one is having fixed working hours and, as in the parent comment, compensating with extra leave if those hours are overstepped.

The other is working overtime whenever there is extra work that has to get done.

People may call it "stupid" but as a meta-strategy or species strategy or whatever, it's actually pretty effective.

There are actually plenty of adversarial situations in which it's beneficial to give yourself a handicap in order to win. If you're playing "chicken" (where you drive cars at each other and whoever turns away first loses) you can blindfold yourself and remove the steering wheel. If you're doing Mutually Assured Destruction, you can set up an automatic retaliation system which you are unable to pause or cancel. By removing some of your options, you can effectively signal to your opponents so that they are forced to respond to your strategy.

Similarly, it can be beneficial to act "irrationally", because if your opponents are rational actors, they won't even try the strategy against you. E.g. If I know you will "irrationally" come for revenge after the fact even to your own detriment despite the fact that it won't fix anything, I might not try something against you in the first place.

Oh, okay... are you referring to fuzzy logic where statements have a partial truth value?

I'm (mostly) referring to the case where the truth value is either true or false, but where you aren't sure, so you can say "80% probability this is your phone".

There are also cases where truth values aren't as clear cut, which I also mention, such as the question of whether or not something IS a chair. (Is a chair taped to the ceiling still a chair? Is a log I sit on out in the middle of the forest a chair? Etc.)

Yeah, love this! I hate when I can't figure out what a software or service does from their homepage.

Looking at oxide.computer... man... what DO they do? Do they sell servers?

My other pet peeve for these kind of websites is when the landing page is full of just release notes and links to tangentially related articles news articles and talks about the product, and it takes me 10 minutes to figure out where I can actually read about what the heck product I'm even looking at, and why I would use it over other products in its class.

This XKCD about uni websites gives the general gist of what I'm talking about https://xkcd.com/773/

Some Github repos are also awful. The README should summarize what the product is or link to a website that does.

The Kotlin and Elm websites are pretty good: https://kotlinlang.org/ https://elm-lang.org/

It's hard to find some really terrible ones right now...

Apache products tend to take some effort to decipher what it is they even do or how they'd be used. They have a nice summary description like the start of a man page, but that's about it. https://ant.apache.org/ https://hadoop.apache.org/

The GitHub landing page is surprisingly worse than you'd expect. It's not terrible... but check it out in Incognito / Private Window and imagine you'd never heard of GitHub: https://github.com/

Compare the above, with how cleanly and clearly Travis-CI manages to express what it does, and why you would use them, along with a useful screenshot of what the UI looks like right near the top of the page, so you can get an idea of what it would be like to use in practice: https://travis-ci.org/

Indeed! I was speaking somewhat imprecisely - I was referring to logic in the sense of Bertrand Russel's work. I should rather say the major shortcoming of CLASSICAL logic is its inability to express uncertainty.

That being said, there are many flavours of non-classical logic and (paraconsistent, multivalued etc.) but their usage remains scarce outside of work in logic itself. Some intuitionistic, constructivist, and computational logics seem to be gaining popularity, especially in computer-related circles (computer-aided proof, numerical methods etc.)

I'm all for using types, and pre- and post-conditions where applicable, but I don't see how they would be a useful replacement to the situations in which probabilities would apply. Could you elaborate?

To give an example where I think probabilities would be used: consider a recognition AI that should figure out who someone is. You have a phone, on which you have some photos of its owner, some voice recordings, and some text messages. For each of those, the AI can assign probabilities that e.g. my voice matches the recordings, my face matches the photos, and my writing style matches the texts. Then it could combine these into an aggregate estimate probability that the phone belongs to me.

How would you use types and pre- and post- conditions to solve this problem?

> Handling uncertainty is difficult regardless; attaching probabilities to judgements did not ensure the social sciences avoided the replication crisis.

Indeed! I'd say that using probabilities is necessary (or at least very useful), but not sufficient for handling uncertainty.

> I'm not sure what you mean by "low flexibility of interpretation": purely logical proofs are supposed to assume nothing about interpretation.

Yes. I found this part hard to phrase. What you are saying is correct.

I meant it in the sense that there are some assumptions made in logic which do not necessarily hold in normal reasoning. As a simple example, classical logic requires no contradictions whereas the average person may hold several contradictory beliefs without going insane (human compartmentalization is there for a reason, after all!). Paraconsistent logics aim to address this. Classical logic also does not take into account the passage of time.

But by "flexibility of interpretation" I meant something like in logic to derive the truth or falsehood of a statement P(X) about some element X, we can only use known facts about X (i.e., previous statements Q, R, S). We pin down a very specific definition which we can interpret any way we want, but we pick axioms Q, R, S to match our interpretation. This is what I meant by the "interpretation of X is inflexible" (poor phrasing). I mean that the properties / axioms are decided at the beginning and do not shift.

However, when we reason in every day life about e.g. chairs, you and I don't start by pinning down an exact definition of what a "chair" is - we assume some shared knowledge and then debate despite starting from different worldviews. During the debate, we might decide to start pinning down a definition of a chair for the purpose of the debate (is it "something that has been created with the explicit purpose of being sat on"? What is "created"? What if I come across a log that I use to sit on every day? What if I take a dining room chair and stick it to the roof so no-one can sit on it?). If you are convincing enough, the way I use the word "chair" in every day life might change. This is what I mean by the "interpretation of the word chair is flexible".

---

My own background is in mathematics and programming, with interest in mathematical logic. I'm afraid my philosophical background is rather lacking. I'm sure such concepts have been described in some depth by various philosophers, but I'm not sure which, or I would just reference the relevant concepts by their common name / link the relevant Wikipedia / Standford Encyclopedia of Philosophy articles.

I'd say the major shortcoming of logic is its inability to express uncertainty.

It's well-suited for mathematical proof as practiced, where axioms and definitions are precisely defined, and there is no reliance on empirical observation with potentially noisy data.

However, most of real-life is not as clear-cut. Deriving the truth of a statement may depend on multiple potentially faulty pieces of evidence which must be taken into account together. For this, one needs to assign probabilities.

This is useful even when applied back to mathematics. In practice, mathematicians form conjectures "likely to be true" long before they are formally proven. Additionally, they must narrow the search space in their minds in order to try the most likely avenues of proof, a process we refer to as "creativity".

Even using probability is only one more step towards solving the question of formally codifying general reasoning. We must also consider factors such as use of language and forming concepts (what precisely IS a "chair", after all?), and further aspects which form a basis for human action and which cannot be logically derived, namely our morality and base goals. Not to mention the entire plethora of such questions with which the field of philosophy concerns itself.

(These are the types of questions to which we will need to find some answer if we are ever to construct a useful generally reasoning AI)

Much as classical Newtonian mechanics is a useful approximation of physics at large scales and low speeds, formal logic is a useful approximation of reasoning at high certainty and low flexibility of interpretation.

Sorry, I don't completely follow. What was mentioned? That there are no simpler solutions to blinding headlights?

The article is very positive about these complex headlights - the only negative mentioned is the price.

I, on the other hand, am quite doubtful about them. There is so much you have to get right to have them run consistently. Such a complex piece of equipment is more likely to break or go wrong in some way, or e.g. perhaps misjudge the wrong thing as being a car and so switch off at an inappropriate time. Is there a manual override, at least?

GPS that takes into account road curvature? That doesn't sound sufficiently fast and accurate.

I'll admit I am ignorant of the tech. It is entirely possible this has all been taken into account, and it works well, and the risk/benefit does work out. Otherwise they probably wouldn't be rolling it out.

My experience with complex computerised systems and software, including in cars, leads me to be distrustful. And there are innumerable instances of advanced technological systems being peddled where the good old fashioned manual way just works better. I say this not as an old Luddite, but as a relatively young software developer.

But hey, reliable software can be built, and has shown itself to be useful in many instances.

I'd need to do more investigation to come to a proper conclusion, but my first instinct is to be doubtful.

EDIT: They don't need to work perfectly. The main question is just, do they work better than humans on average and when it's important?

This seems so much more complex than it needs to be. Basic solutions are consistent, predictable, reliable, cheap, repairable, replaceable.

Surely there are simpler solutions to the "blinding headlights" problem?

Humans exceed our current computers in the same way that a large asteroid impact exceeds our current nuclear weaponry. It's a matter of scale, not of kind.

If we track the capability of computation machines from binary adders through old-school chess AI, expert systems and robotics, to the neural networks playing Go, chess, Starcraft, DOTA, we see an ever expanding sphere of ability and influence - often exceeding what humans predicted was impossible for computers.

> Of course, you can always say there is a yet undiscovered algorithm to fill the gap between state of the art and human performance

This implies a kind of asymptotic approach towards human intelligence, that it's something we keep trying to approach but will never reach.

But beyond "filling the gap" I believe computers have the potential to shoot past us in ability. And if they do, I think it's going to be a pretty shocking experience, because I think the rate of increase in intelligence at that point is going to be bigger than we expect - there's no reason to believe the exact level of intelligence is a special border, objectively speaking.

To claim that the evidence so far supports the uncomputable mind hypothesis seems to me like if we had managed to build tiny motors which had been getting bigger and better each year, and then claiming that we would never be able to beat an elephant in strength because no motor up to that point had yet been able to do so. Yes, our metaphorical motors are still tiny, and yes, it takes other extra pieces of engineering beyond motors to actually push down a tree, and indeed it's possible we will perhaps never build a big enough machine. But to take each larger motor as somehow being evidence AGAINST us ever getting to that point is a strange viewpoint.