ezy

Often the software and OS APIs on that system are glossed over in favor of the hardware or the graphical shell. The Exec[1] was a marvel at the time -- and in some ways, still is. I don't know how much ARexx[2] preceeded AppleScript, but it was also, something that other OSes seldom got right.

It took other user-oriented operating systems about a decade to catch up, and in fact, the hardware everyone raves about in the Amiga fell behind far sooner than the system software.

[1] https://en.wikipedia.org/wiki/Exec_(Amiga) [2] https://en.wikipedia.org/wiki/ARexx

I'm going to take issue with this. This has nothing to do with having a solid computer science background -- in fact, I've seen way more architecture astronauts with CS degrees.

It has to do with learning stuff on a lower level -- whether or not you attend a school to do so. Us autodidacts who grew up on assembly language and C code will beg to differ on your use of the word "prevents".

Didn't everyone use this all the time to pause 300 & 1200 bps output in the days before screen and scrollback terminals? :-)

I understand the PIC technique, but I'm having a hard time understanding how this is different from what a trace might do. That is, inline the impl of method_missing and then optimize the most common path with guards included. Or is it that I'm being too optimistic about the tracer -- and with a generalized PIC one isn't relying upon the tracer to get it right, but forcing a cache on meta-object protocol boundaries?

I get that you want to make people aware of the tool and its advantages because you think others might find it useful. But what part of that requires any attention to the condescending idea of "messaging" vs just straight up telling people (a) what it does and (b) why you created it.

Anyway, perhaps I'm being a grumpy old man late in the workday, I'll leave it be :-)

"I find that position to be very hard to understand - devtools live or die by their adoption"

Some of the time, that is true, but not all the time, maybe not most of the time -- you are putting the cart before the horse. In fact, I would argue that this is an anti-pattern. Yes, you might use (e.g. to pick 2 unrelated domains) Hadoop or Python because they are popular, but consider how they got popular in the first place.

Devtools exist to solve a problem. You should not evaluate devtools based on the webpage or how many people are using it. That way lies Oracle enterprise. :-)

The problem with Docker's website is not that it exists. It is that it substitutes sales & marketing for just simply explaining what it is to a developer. While one could classify this under the category of "marketing", it would be a mistake -- kind of like classifying man pages as sales pitches. Just tell me what the fuck it does for god sakes and I'll decide! I could give a rats ass whether Facebook uses it, etc...

To be clear, I find Docker, the tool, useful, I just think it doesn't need "Marketing", it needs a useful webpage.[1]

Ruby was not adopted because of its webpage or its user base, it was adopted because one person bothered to look into it, liked it and decided to build a very popular web framework around it. Others saw the value in that domain and it exploded. Similar situation for Linux, which started from an FTP site and usenet posting. :-)

"The nerd-centric viewpoint that tool should succeed entirely on their own merits, with no affordances for the user, is crazy."

Unrelated to what I was talking about entirely. Affordances to the user is a merit of the tool itself. Docker could be considerably easier to use in some regards, and that would improve it's usefulness as a dev tool. However, this has nothing to do with attempting to gain marketshare with no direct relation to merit.

[1] But then Docker, the organization, is selling something, aren't they?

The problem is not that they "message themselves" (gross) wrong, but that they feel like they have to "message" at all. Sales & marketing mumbo jumbo has no place in devtools -- it is at best, obfuscation -- at worst, misrepresentation.

This is overblown.

The lisp is not "rendered", it is executed. Any language that can implement a recursive-descent parser/generator could be the basis for this -- it does not require lisp or lisp macros. Think about what a render would have to do, and you realize that the model of using embedded rewrite rules (macros) might be slightly more convenient, but not a really a distinct advantage over executing code which renders or outputs instructions to render later.

The problem is most definitely not that you have to output an intermediate language, the problem is that HTML/CSS sucks. It is originally designed around presenting static text documents, and the committees involved were not smart enough to figure out a way to depart from that over a decade ago when pixels became important to the web.

"Many of the usability issues raised by Don Norman in his 1981 criticism of Unix have gone largely unaddressed"

That's because Don's complaints were not about intrinsic issues, but complaints from someone who had a frustrating time developing a mental model of the components of a system and who tried to use the just-so story of "cognitive design" to justify his inability. The non-point about prompting y/n to delete is particularly misguided.

Similar to this article.

"ls" is called "ls", not because of slow 80-char terminals, but because humans are, on average, not fast typists. One wants to list the contents of a directory a lot, and "ls" is quicker than "catalog". Similarly, "ps" vs "tasklist" and "cc" vs "compile-a-c-program" :-). Notably, in powershell, most people have aliases that do this for powershell's necessarily verbose query functions.

It's primarily a command shell for controlling the machine, not a programming language. And the UI choices made over the last 30 years reflect that.

That fact that ls takes arguments is a UI improvement that keeps you from having to write tiny programs all the time and pipe it's output to sort and awk all day long. It is also why the "one job well" crew is only half right, and why Powershell kind of feels awkward even though it seems to get more things "correct" in that regard.

This is just yet another just-so story by someone who wants ideological purity in UI, which is completely misguided when UI, by definition is oriented towards a universe which is not ideologically pure.

If you buy into the prose/code relationship, this is silly. It is like complaining about an author using prepositions.

Depends on what your your qualifications are for a touch typist. There's a considerable distance between hunt and peck and someone who never looks down.

I can touch type for stretches because I learned the location of the keys organically -- but I've never had (good) formal lessons and have to type a lot of punctuation which is two rows above my fingers -- so I move my hands a lot[1], don't make use of the fixed position on the home row at all, and I end up looking down way more than I probably should (usually at the starting point).

I do about 30-40 wpm on the website above[2] :) Which is way slower than someone I would call a true touch typist, but not slow enough to impede anything but raw transcription.

[1] I have no real evidence, but I think this tendency to move my hand instead of reaching with my finger has let me avoid the repetitive strain syndromes associated with typing, as well. (It could be just that I take minibreaks every 30 seconds to look down :-) :-P)

[2] If I try to do it the classic way.. it's 10 :-P

Ah, I didn't catch that. That's... annoying.

Perhaps you might object mathematically too. I think of a curve as fitting the test scores to a specific distribution as a corrective to testing error. It's not the fitting that's the issue, it's how justified the target distribution is. If you truncate it, you have to justify doing that somehow (all prior test results had that distribution?). Of course, if the sample distribution squashes it enough, you might end up clustered at 100% anyway, but...

At the risk of sounding completely ignorant, what's wrong with what she did? In most classes I've been a part of, your total score was based on a weighted average of scores on particular tasks. The normalization here is a typical test curve -- a normalization that attempts to compensate for measurement error in one particular test, independent of the total class score. That's why she referred to "extra credit".

Oh well, we will not agree.

Again, I will say, especially to your concluding remark, this is a distinction without a difference. Because (eg.) if someone is prejudicial against a human with breasts, that does not make them simply "breast-ist" because to boil down to that level is ridiculous and entirely context-free. SImilar to everything youw rote, because all of this is occurring in a particular context.

Ok, I think I see where we depart. To me, treating women as sex objects in the workplace is absolutely part of sexism, and that's probably her assumption too. I see how you might make a distinction, but I don't agree with it.

The idea that the harassment wouldn't happen if she were old and ugly doesn't make it not about sexism -- anymore than a guy who only patronizes a certain kind of woman (the kind he is attracted to) is not sexist because he doesn't patronize all women equally.

There is a sense which (I think) you're going for where this could be thought of as people latching onto things that are "out of the norm", rather than specifically sexism -- but that seems tautological to me. All -isms (that I can think of) are based on pre-judging based on things that are non-normative: sex, race, age, orientation -- you name it.

What is the norm that she's violating? Well, it seems (to me) to be existing as a (technical) woman in the workplace and all of the attributes that come along with that -- like a human that speaks in a higher register, or wears dresses or doesn't wear t-shirts as regularly.

This is, again, not uncommon and therefore the most likely explanation for all of the things she's encountered taken in totality. "Culture fit", which you refer to, is about prejudice -- and each time the type of prejudice may differ (between racism, sexism, & agism, let's say[1]) but it's still prejudice, not some magical other thing.

[1] suit-ism, let's not forget suit-ism. :-)[2]

[2] Sharp dressed -ism?

> Wow, way to go! I read HN so I must be a PG cheerleader and ergo I'm definitely sexist!

For someone who is all about psychological errors, you seem to have constructed quite a narrative. I'm not talking about cheerleading -- just the level of analysis. I'm not trying to make you into some horrible monster or anything -- that is your projection onto my criticism.

Speaking of psychological blinders: I stand by my assertion that, as long as anyone doesn't mess with your ego, you will not apply this level of analysis to what they write. It's human nature. At the risk of repeating myself, I just don't think you're reading PG's articles and thinking that what he says happened to him, didn't happen.

> Should anyone be able to wear anything to any job without any consequence?

Oh come on. Really? RTFA. You're veering away from the misattribution you original claimed as a possibility here.

I just wrote a whole comment about context, and you ignored it because it bruised your ego. Being obstinate about "drawing a line" is not a triumph of reason -- it's ignoring the world. Reductio ad absurdum relies on symmetry, of which you have none here.

She's obviously not wearing hot pants, a bikini top to work, and even if that were the case, she would be notified in an official capacity in short order (e.g. "told to go home") -- not "complimented" repeatedly in a creepy way.

There is no "murky line" because we are talking about a repeated pattern she illustrates in her article which shows it highly likely not to be misinterpretation. If she misinterpreted one of those examples (e.g. the "Facebook" example is the one I'd choose, actually), ok. But how likely is it she misinterpreted all of them, and the misinterpreted the social environment that made her pull together the examples in the first place?

> Please realize that there's a difference between saying "it might not be sexism" and "it's definitely not sexism" and that I'm trying to very cautiously propose the former, not the latter.

If I have a bug, it might be cosmic rays, a compiler bug -- or it could be my shitty code. All of these are possible. It isn't about what's possible, if you want to be analytical about it.. it's the likelihood.

So, when you say "it might be a compiler bug" when code breaks, you should know how ridiculous that sounds, even though you are technically correct[1]. There is a reason people say those kinds of things (without much more evidence) and it has a lot to do with how attached they are to their code.

[1] The Best Kind of Correct.

Well, duh, but the whole thing about "invalidation" is there is a subtext here: that she wouldn't know that she had been misattributing sexism to someone.

If all your friends with Fords of various colors and models had problems -- you would rightfully have cause to focus in on Ford as the problem.

Do not pretend to be objective by discounting context, or acting like everyone else is an imbecile. I'm not saying that everything everyone says has to be taken as truth. But think about the context for a moment -- like why is she writing the article in the first place? It's no small thing to put your name out there on the internet WRT to this issue.

Think about how analytically you are viewing what she wrote about her experience vs. how uncritically you might view articles from PG (especially the earlier ones unassociated with YC).

That sounds like a weird off-hand complaint until you realize that she's not talking about once or twice -- she's talking about "making it a point" to do so. Even once or twice is perilous territory, unless it's in a particular context (she brings up the subject in conversation, for instance).

That is, he was attracted to her, and wanted to let her know it. This comes up a lot when people believe that anything said with "positive intent" to women is actually positive. A lot of geeks don't get this. Women aren't stupid -- they recognize the compliment for what it is. Whenever you feel like you need to say something to a woman because your genitals throb -- think better of it.

I've made this mistake -- it was subtle, not egregious (like the guy above), but I did. Nothing happened, and maybe she never noticed, but in retrospect, it's one of the those embarrassing things you do in life you get to re-live in idle moments. Don't let this happen to you. :-)

It's important to understand that sexuality comes up everywhere. In our work cultures, we generally try to suppress it because even in an office with all men, it can become a distraction.

With women in the workspace, it's much worse. Our society trains us to think of women as sexual objects who must always prioritize a man's perspective. Even if you are "enlightened", it's easy to slip up if you're too casual about it. When you want to offer a compliment on someone's appearance (in a nominally non-sexual context), you need to understand where it is coming from -- and do not lie to yourself. It's okay to be sexually attracted to someone in the workplace (that's humanity), but not ok to impose your desires on someone else without their consent.

Focus on why you are trying to accomplish something, not how you are accomplishing it.

Yes, these are tricks, because "lazy" means you're storing thunks and significant partial results with no outward indication of such. Just because you don't see it, doesn't mean it's not there. I could say the same about C's allowance of global state, or spurious use of recursion without a depth guard.

To your examples:

A trick, because who would ask for a constant from an infinite list that could be generated numerically in a fraction of the time?

A trick, because for random queries of large n, this is not the optimal way to compute it (the optimal way is more complex). It also entangles memory allocation and the computation. Note how haskell is "side-effect free" for fibs, yet somehow memory allocation or the time required for allocation is not considered a side-effect when I ask for "fibs !! 2000000". The C iterative solution is trivial, and will execute faster.

A trick, because no one cares about fizz-buzz being extensible, and this is not particularly clear to the reader compared to an ordinary if/switch/case expression.

> What we're speculating about here (at least I think we are?) is if this is a sustainable model for general development and if we can do better.

Here is the kind of difficulty I'm talking about. Instead of thinking about this on a continuum from Aeronautics & medical (where people could die) to yet another throwaway web TODO app (e.g. "general dev"), there is this tendency to say that they are "completely different" in some way. Let's be clear, the theories do help both. Side-effect free programming is useful. But you cannot take theory and just map it directly to the real world with no caveats. Just because Haskell tracks side-effects, doesn't make it superior to C in every context.

The Mars Rover shows this clearly -- C was chosen because someone was used to it, yes. But the part you didn't catch was the implicit decision that it makes no sense to use a compiler and ecosystem you don't understand the caveats to when you need to understand all the caveats to build a successful system.

Similarly, the TODO app developer isn't using Haskell because Haskell doesn't have anywhere near the libraries Python or even Go does, and building and deploying Haskell programs is somewhat of a chore compared to those. It's no contest, Go is superior to Haskell. :-) It's also one of the reasons almost anything is superior to C/C++ in this very same domain. :-) It's not about being "entrenched", because Go is way, way younger than haskell -- it's about the priorities the language designers and developers for that language have -- ie. the culture.

> If we can get our specifications right, the rest becomes trivial.

This is what I mean about theory and practice. Note the big "if" there. I totally understand the sentiment, and I wish it were true. I even have my own meta-programming based language in the wings I'd like to release some day.

But the reason I've stalled a bit is I've never seen this work in practice because our minds (and specs) tend to paper over the devilish details. I'm not saying we shouldn't use meta-programming, I'm saying that it should not become dogma. Invariably, you get caught up in details. This kind of domain specific "meta-programming" is a great bootstrap technique, but doesn't appear to be "the way" programs should be written.

The OMeta folks created a TCP stack that compiles (almost) directly from the specification. But that was a academic exercise. How many special cases do you think they cover? Does anyone really believe that the stack in question is anything but a way to bootstrap a more robust/performant implementation later on?

Similar for the PyPy folks. Yes, you can JIT compile a python interpreter, but how many years have they worked on special cases for that, and how much farther would they have gone if they hadn't used the meta-circular approach and just addressed the real problem to begin with[1]?

> Compared to compiler-assisted reasoning about side-effects, the difference between SML and O'Caml is completely trivial.

I think as a general statement, this is true, but is a poor way of thinking about things. You're not comparing OCaml to SML, you're comparing it to C++ or Java. If all the language brings is side-effect reasoning, it's not enough, because I can add decorators to C++ code to do what you're asking.

Even with "side-effect handling" these languages don't assist you with all of the side-effects someone actually cares about. Is there a decoration for runtime speed, for memory consumption, not just for IO, but for the amount of IO? Is it even predictable? These are the real things people care about, not just whether a function peers into some global state somewhere (although that is an important thing to track, it isn't the biggest issue, IMO).

> Your [2] is just absurd :). Clearly, you don't have to understand the body/implementation of a function, just its type :)

Is this sarcastic? :-) I mean, anyone with a reasonable amount of experience knows that this is not true most of the time.

It's not completely false -- one doesn't always have to look at the implementation of the operating system facilities or even the standard library. But in code that is less than tangential to what you're working on, you certainly do end up having to understand how it's implemented. As a developer, you spend more time reading code others wrote than writing it.

> More seriously, I'd be interested if there's a particular experience that soured you on FP (or perhaps Haskell, in particular)...?

I'm not soured on FP as a concept (which could mean many things, but I just mean state-awareness), just haskell. The <space> fn call operator combined with currying in particular seems like an advancement to rubyists[2] and those think succinctness is a virtue above all others[4], but it is an engineering disaster -- completely unreadable at the call site unless you know the arity of every function by heart.[3]

But maybe I've just read bad code... I'm not dismissing that possibility. :-)

[1] The problem with python was never optimizing plain python (look at JS as an example) or the "GIL", the problem was (stupid) performance requirements about the GIL from guido, and later on, C extension API compatibility.

[2] Do not get me started on the "domain specific language" shit-fest that ruby (and progenitors like groovy/gradle) have unleashed on the world. At least stack overflow gets money and page views from it, I guess.

[3] As much as people like to put down smalltalk (cum obj-c) keyword argument syntax, it is a revelation when you're maintaining code (and I'm sorry Swift seems likely to drop it as a default).

[4] Is Arc (PG's lisp) used anywhere significant, but for this website?

(Note, not being critical of you, just placing this here because I was thinking about it recently)

Maybe because CS is so young, there is a tendency to confuse theory and practice.

Whether a particular language makes one more productive isn't math, it's engineering. When we talk about how monads might allow you to separate concerns and relieve a mental load -- we are talking engineering. When we talk about how monads compose, we are talking abut the math/science that enables the engineering. They are both related, just like mechanics is related to mechanical engineering, but they aren't the same and they have different concerns.

Be wary when you start thinking in terms of "entrenched interests". It's tempting to go down that road, but the reality is that those "entrenched interests" actually have good engineering reasons to be that way[1]. It isn't like a million other programmers haven't noticed that FP-style programming offers some benefits -- but often the benefits end up not out-weighing the drawbacks in the languages, ecosystems, and practical performance and hardware concerns.

This should be obvious, but I think people start muddying the waters -- especially when they focus on the ideological purity of their programming language. Programming languages are tools. The most popular ones are engineering tools -- and there are some not so popular ones that are tools for exploring the math behind the language itself. There are too many tradeoffs to have a language which occupies both spheres successfully.

In particular, the FP advocates go round and round on this issue. Just because something is elegant mathematically, does not mean it's good engineering practice. Haskell, for example, can be practical, but it struggles between the math and the reality of limited machines and human cognition[2]. Likewise, when you start talking about SML vs OCaml, you're talking engineering, not math -- and possibly a language tailored to engineering vs math.

You see this in languages like C++ too, where practicality starts giving way to a kind of semi-mathematical, yet totally non-scientific, dogma about how programs should be constructed based on their respective committee-designed[3] standard libraries.

[1] not always, but more than people really give others credit for.

[2] I still maintain Haskell is a write-only language, like an opposing pole to perl. Not (completely) because of the language itself, but because of the culture surrounding it which glorifies one-liner lambda calculus/laziness tricks over engineering pragmatics.

[3] e.g. compromises made in absence of any real on-the-ground engineering constraints.

Eh.

One of the many libertarian lies is that all uncoerced transactions are somehow value-neutral. For example, it's certainly a valid question whether it's ethical to support a weapons manufacturer, for example, no matter who's buying.

In this particular case, I think this is an ethical positive. I would classify MJ funding as a net good, as it will encourage legalization -- prevent a lot of wasted resources and people.

On reading this, my first question is about the properties of the "random" feedback matrix. They illustrate what is happening using a tiny 1-width machine and a "random" matrix of "1". It seems like some analysis needs to be done on what kind of "random" is most appropriate to replace the gradient update for larger machines. There could be something really interesting going on such that you could generate some optimal non-random B according to whatever the network topology is.

Have you read the implementation of the python collection types (list, map, etc.)?

Yes, but (according to the spec) it was stateless -- which made it worthless for the purposes I'm describing. The original purpose was to support custom static strategies for allocation (e.g. i86 near/far pointers or one memory pool for one kind of object for the whole program), not dynamic memory pools and arenas. C++11 fixed that, which is why I mentioned it.

That said, by C++03, most STL implementations supported stateful allocators (and that's what I've used when I've had to use C++), but the standard took a while to catch up.

Yup. That's excellent. Rust changes so fast, I can hardly keep up. :-)

I prefer well known memory lifetimes, but I'm undecided about ARC (or somewhat equivalently: std::shared_ptr, etc.). It can be a little confusing and overwrought at times, and I don't think the lifetimes are as clear as they could be.

IMO, more languages shouldn't assume that there is a single memory allocator. That's one of the worst assumptions I see in systems languages -- even C++ (before C++11) got this entirely wrong. Swift gets this wrong, Go gets this wrong. Rust is probably a little better because it actually has a static idea of memory scope, but I haven't seen a way to swap out the memory allocator in various contexts.

Most projects I've been involved with have used region/arena allocators. Not only do you mostly avoid the non-determism of your average GC, but you avoid the hassle of fine grained reference counting (in most cases). This relies on you choosing the scopes for your regions appropriately, but there usually is a clear scope to attach things to (e.g. frames, iteration of an event loop, etc.).

Well, the goal is for it to be minimal, and C doesn't actually do a lot of work for you. On reading it, the algorithm it uses to parse was of less interest than the various tricks it uses to initialize and manage the state of the parser in a compact way.

Wow, I thought I was the only one who preferred that WM. I should try and get it running in my ubuntu instance again...

Beyond the Hawkins-driven hype, I do think, however that it is worth attempting to model the brain more closely in ML. It may be that, practically, the whole HTM thing doesn't really work out -- but it will be interesting to see how it fails or succeeds as a research project.

Just like NNs in the 90's, there is this tendency to write it all off when some other technology does better, but I have a vague hope that at least some of the ideas will be more widely useful and that it's isn't a totally wasted effort.