aeorgnoieang

> it's not a great modern language for a lot of internet or IO stuff

I think Clojure is a great language for internet stuff and possibly great even for IO stuff too, depending on what you mean by that. The LISP-iness is probably better for the former but builtin Java interop probably goes a long way towards being pretty-good for the latter.

What exactly were you thinking-of by "IO stuff"? Graphics? Embedded systems programming? I'd think Clojure could be just as good as Java or Python for all of those, tho existing libraries aren't going to be quite as good as C/C++, and Go will probably be better-performing generally.

And there are (because of course there are) LISPs for real-time embedded systems programming:

- [nakkaya/ferret: Ferret is a free software lisp implementation for real time embedded control systems.](https://github.com/nakkaya/ferret)

You're right about the 'homoiconicity' but there's more LISP-iness to JavaScript beyond just "processing lists" too.

No, even the original language was pretty LISP-y.

I'm not sure there's anything now that 'LISP' could refer to beyond the family of languages, of which Clojure, Common Lisp, and even Scheme are all 'modern' dialects.

JavaScript is, probably somewhat surprisingly, a pretty LISP-y language, tho without the parentheses.

It's elegant. It's (relatively) easy to write a basic parser. LISP code is readily expressible in the same basic data structures provided in the language so you get meta programming almost for free and thus extending LISP is (relatively) easy too. Whereas C feels like an abstract machine language, LISP feels like an abstract 'mathematical computation' language. It's, like all languages, a different way of thinking about computation in the same way that human languages also seem to be (at least marginally) different ways of representing or expressing thought.

And once you've come to appreciate it, jokes like "HAVE YOU READ YOUR SICP TODAY?" will be funny to you.

In terms of 'getting shit done', it's not so 'good', not that one can't get shit done with LISP, but that it's not necessary nor, given all likely real world constraints, particularly that much of, if at all, an advantage relative to other (families of) languages.

It's also historically important so there's a benefit in knowing about it and being familiar with it too. And knowing the history helps understand why people still love it, even as a lot of what was once unique or special about it can be found much more widely.

I can only understand [3] based on what the author wrote. But it certainly seemed like it really was the case that generally limiting the number of items to 10 was fine. And, based on their subsequent observations, there was no practically realizable situation that would result in more than 10 items, let alone 100.

Lots of terms – really, every term – is fuzzy at some resolution and thus all understanding is inevitably fuzzy too.

Empirically, you seem to be almost entirely wrong about people not understanding the consequences of their choices. It's absolutely true that sometimes people are wrong about the consequences, but that's true even with financial debt – maybe the interest payments on some debt that should have reasonable end up being the straw that broke the financial back of the organization.

> Bad design choices cost you over and over again.

In the sense in which you seem to mean this, this is a ridiculous statement because every design that's not perfect, and none is, must then be a "bad design choice". That's just not true in any reasonable interpretation.

It's also unclear why invoking 'tech debt' precludes a clear analysis or articulation of the relevant situation. And regardless of whether anything is quantified, it's also inevitably 'fuzzy' too. Why would quantification itself be good?

Take the first example from the article – implementing a 'bad' version of the component to actually send emails. They did this, consciously, because they wanted to test the editor component first, before implementing the more robust email-sender version. And they did supposedly quantify a lot of that 'technical debt' – they estimated how much time they'd need to implement the initial throwaway code and how much time doing that would save in terms of them being able to more quickly test the editor. And they seemed to have a very clear idea about what exactly was wrong with the initial version and thus an approximate idea of the costs of not eventually replacing it with a better one later.

> Write a paper then and show me the money, so to speak. Quantify this. Because the only "great benefit" I've seen of the term "Tech Debt" is to the ego of the individual or team that invokes the fuzzy term.

The blog post for this very thread is a good example of the great benefits of thinking in terms of technical debt! You should write a version of the same blog post, using all of the same examples, and clearly indicate why using 'technical debt' is pernicious and furthermore how exactly you'd have dealt with all of the same issues and considerations mentioned.

> Spatial expansion doesn't move anything, so it can't propagate information.

It certainly moves matter-energy in different regions of space with respect to one another.

> It doesn't cost any more to have equipment sending packets as it does to have the equipment idle.

I'm not sure that's even true. I'd expect power consumption as well as 'wear and tear' to be less, and possibly significantly so, at idle versus continuous use.

> Data caps are a measure invented to extract money, not serve customers or packets.

Some people will definitely test the limits of anything that's supposedly unlimited. I imagine you're partially correct but I suspect data caps are the most comprehensible product attribute for ISPs to limit the relevant costs.

> If the cable companies were worried about fairness, they'd really be speaking in terms of bandwidth reservations at peak times and encouraging use during off-peak hours, and similar things.

I'd imagine that'd be an even harder sell than congestion pricing for motor vehicle traffic. It is mostly just a 'fact' of the world that almost everyone is going to want bandwidth at the same times. The costs of transitioning to any other arrangement are considerable. And Netflix is probably the player most able to adjust. I'm not sure if they still do, but they did at one time host a lot of their content in ISP data centers.

For [3], it seemed pretty clear in the post that the limit was 'arbitrary' in that there was business reason to impose some limit, but no specific limit was motivated by any reasonable "intentional" or "clear" thinking, and that, moreover, trying to discover some kind of reason was unnecessary and thus wasteful to even try. The author clearly points out that, apart from the limit, there is no need for "transactional correctness', i.e. no other part of the system required that the limit be strictly enforced.

And if that was some day no longer true – if they realized later that they really did need "transactional correctness", then it still seems like they may have made the correct decision in incurring technical debt, especially given that the author mentioned that the limit was never exceeded in production.

If that system did in fact require a hard limit then they probably would have focused on implementing "transactional correctness" as that would have then been a core feature of the system.

I can certainly sympathize with your comments in this thread. But all of your examples rather seem to confirm the utility of the analogy/metaphor as it's certainly, clearly, true that some people incur too much technical debt and are never able to 'pay it off' later when it comes due. That's not a knock against the analogy but instead a mark in its favor – debt should be taken on mindfully and carefully.

Contrary to what seems to have been your experience, I've seen technical debt incurred to great benefit.

I think it's pretty clear that there are often, clearly, no right answers to a lot of questions.

The answer to "Does my system need to handle 1M concurrent users?" could be "Yes", "No", "Not for the foreseeable future" or even "I don't know".

Given that 'debt' is a way to, in effect, allocate (possible) future resources today, it's pretty clear why it's valuable, especially in the face of uncertainty.

An unexpected tech debt jubilee!

Not all spending is wasteful, even when, in an ideal scenario, it could be avoided.

I'm curious what you think is better. Any links you could share? I suspect you're wrong, or not quite right, tho. Technical debt is a great analogy and even if it's fuzzy, being able to think about the relevant tradeoffs in a familiar way is too useful to ignore.

Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being made.

Based on the man page it captures the 'screen' for all monitors unless otherwise constrained by options.

The sentence you quoted would make more sense if you interpret "is really just" like a mathematician, i.e. they're 'equivalent' in the sense that you can 'map' everything important about either in both directions.

More concretely, "an optional" is something that either 'has a value' or 'does NOT have a value'. So it "is really just a list constrained to size 0 or 1" in the sense that an optional that 'does NOT have a value' is equivalent to a list of size 0, i.e. a list with no contents/members, and an optional that DOES 'have a value' is equivalent to a list of size 1, i.e. it's 'value' is the single/unique member of the list.

Think of statements like 'is really just' in the sense that an integer between 0 and 255 'is really just' 8 ordered bits – they're 'equivalent' in the sense that you can map all possible values of those integers to all possible values of 8 ordered bits, and vice versa, and (importantly in a mathematical sense) in a way such that every integer is mapped to a single set of 8 ordered bit values and every set of 8 ordered bit values is mapped to a single integer. In mathematics that's often described as an 'isomorphism' which is, in working programmer terminology, just a way to convert back and forth between two sets of values 'perfectly and losslessly'.

I've been programming in Elixir for a few months now, and I like it a lot, but I found your comment amusing because a lot of Elixir's 'macro expressivity' seems to be due to Erlang using a data structure for its own parsing that can be readily manipulated as 'first class citizen' in itself. That's basically what s-expressions do. Apart from a small number of things that most people otherwise encounter in 'infix' notation, e.g. arithmetic, s-expressions seem to be a radically, and brilliantly, simple form of writing programs in a way that makes meta-programming as simple as possible.

(And, of course, meta-programming is powerful, thus 'dangerous', but there's a lot of things that are only really feasible with it.)

Nah, blame the regulators too for thinking that filling out paperwork is likely to meaningfully dissuade someone from using human remains to make dog food. It was probably sufficient to explain to that one guy why that was bad.

I think this describes a lot of reasons why 'classical classical' music 'sounds' very flat, emotionally, to me, compared to modern music. I do generally enjoy a lot of 'neo-classical' music tho, so I think you're probably very much right about why.

It would probably be only marginally more expensive (for Twitter specifically) for them to add changes in a way that's backwards compatible with older clients, so I don't think this argument is particularly convincing. I think, because it's somewhat plausible, they pushed it, but because they really wanted to control all of the clients, to increase their advertising revenue.

Of course it depends on the nature of the specific change. I'm sure lots of developers really appreciate bug fixes, especially for bugs they've encountered, let alone developed workarounds or patches.

But there's a reason (really, lots of reasons) why it's a great idea to pin one's third-party dependencies. Change is, at least, costly; at beast trivially so (but never literally nothing).

Yes, and customers do very much vote with their wallets, even when the costs of switching exceed the benefits of switching!

What kind of bike, or most other physical products, get updates or upgrades for free whether one wants them or not? Certainly physical products with software and networking can, but people are often upset when that happens anyways. I'm pretty sure almost all bikes are not in fact automatically updated or upgraded after they're purchased. And that's essentially a 'feature' now in comparison to a lot of software purchases.

> You're not being honest here. If you can't imagine it, it is because you're not trying.

I was being honest. Please don't tell me I'm lying; assume good faith. I still claim that his wording 'Wolfram Language gets it right' versus 'Wolfram Language got it right' would leave a layperson with the impression different than what you claim.

I could be wrong. I'd be willing to make a (nominal) bet about the outcome of a reasonable proxy if you're interested in testing our disagreement. I'm not claiming near-certainty tho. I don't think you're 'definitely' or 'obviously' wrong.

For the second example, I think his cellular automata is a pretty good way to see a phase transition. I'm also interpreting his claim pretty charitably, e.g. not that it's literally the clearest way for anyone to see, let alone understand generally, for whatever reference class of 'people' would possibly be the best definition to use in this case. I think you're splitting hairs pretty finely here.

I do agree that his writing style is "grating and self-serving". There's lots of evidence that that's the case, just in the comments on this post alone. I think part of that interpretation is warranted and valid. I think another, significant, tho lesser part is confirmation bias.

Stephen Wolfram definitely doesn't have all the answers for me, or likely anyone. I'm pretty confused why you wrote the last sentence in your reply to me. I think my comment was pretty anodyne. You seem to have pretty strong feelings about it.

I'm also unsure why you'd think an "investor" would be particularly interested in him or his companies. Wolram basically sells enterprise software and related services. It doesn't seem like a likely undervalued opportunity for significant growth.

I'm also unsure why you think anyone would "worship" him as a "savior". I don't regardless.

I'm happy enough to wish him and anyone that's jumped on his bandwagon well tho. I think he's got a very good point about the likely benefits of engaging in what I'd call 'exploratory computational discovery', as he describes in NKS. Yes, he uses much stronger and strident language to describe the same thing, and I think the magnitude of his claims are too large, but I do think his point is underrated, even significantly. I'm more skeptical of how much low hanging fruit there's likely to be from applying methods like what he advocates, but not radically so.

You 'sell' or 'gift' the rights to all groundwater in a suitably defined watershed and that controlling entity sets prices (and at least partially enforces their rights). The controlling entity could be a government organization. A private organization would need either some kind of cooperative police apparatus (with the ability to detect, and stop, violations of the controlling entity's rights to the groundwater).

The key is to 'sell' or 'gift' the property rights to the resources that were previously part of the commons (and to a party that can economically protect their new asset).

I'm hoping one day something like that will happen with fisheries, e.g. someone will own fisheries or maybe even schools of fish. Anything less seems doomed to tragedy.

Note that government management of a previously 'commons' resource is, in theory, the same basic arrangement. In practice tho, the very different incentives shaping government organizations doesn't seem to as reliably protect resources as for private entities.

('Markets fail'. Governments fail too. What's the expected difference in the rate of failure of the two?)

The advice seemed to be to, first, support (i.e. correctly ignore) any possibly new value in both the client and server (i.e. any client of the 'schema').

Skeema looks cool, and I've long been a fan of a similar tool that's specific to SQL Server – DB Ghost. I even implemented some pretty handy additional automation on top of it at various companies at which I worked. There were tho, inevitably, a small number of schema changes that needed to be encapsulated as 'migrations', and it could be arbitrarily complex and difficult to write, and test, them in a way that supported automatic rollbacks.

If they're in anything like the last situation I was in that seems similar, continuous deployment may not be possible – not technically, but with respect to other considerations, e.g. management or even the business's finances.

There's still a lot of small software companies maintaining, and selling, on-premises installations of systems that use, e.g. Microsoft Access as a front-end client. Even then, continuous deployment is possible, and all-else-equal, a huge improvement for the developers and support staff, but also something that lots of management or owners may be (reasonably) averse to committing to implementing.

I'd hope so! It's $795 MSRP in 1974 'is' roughly $4,100 in 2019.

There were several references to fish populations and and even "population biology". I wouldn't have thought 'population ecology' was that different but a cursory Google search leads me to believe I was wrong.

That's a neat connection!