ctrlmeta

Ah! Finally it clicked! Thanks for the nice example in your comment.

> Expected time refers to a single operation. Amortized time describes the mean time of a series of operations.

Pardon my ignorance but I don't see the difference between these two sentences.

Expected time of a single operation = Sum of time taken for all possible input cases / Number of cases (assuming each input case is equally likely to occur). Is it not?

Isn't it then the same as amortized time?

Exactly! An unfortunate truth about running live and complex services is that they break frequently in strange and weird ways and we need to write a fix as quickly as possible, get it reviewed quickly and then roll it out asap. The term "hotfix" literally comes from that. The time range to develop and apply hotfix can be 30 mins to 48 hours--depends on nature of issue.

It does seem like a recipe for high inflation. But I want to understand why they chose this combination? Why play such a big gamble? There has to be some logic behind making this choice. But what is it?

Were there other safer alternatives that they could have gone with? What could be the reasons for choosing this combination over those safer alternatives?

Very good list. As an open source user, I want to add that I look for two types of writings when I am trying to use a new open source project.

The first type has official tutorials (not full reference, not API docs, but official tutorials). It helps me to learn how the project authors/maintainers want me to use the software.

The second type has blog posts and articles written by other users of the project. These are unofficial, informal posts that shows how the software is used by other people. They help me to learn alternate ways of using the software, learn what problems others faced and how they solved it.

Any contribution in these two types of documentations are sure to make good impact on a good number of users.

Yes! It surprises me that the reliability issues in charging an EV are not discussed more. This bears more discussion and subject to regulations. It is not ok for companies to push EVs to general consumers without creating a good safety record.

But how many work areas have a charging station available easily?

> We’re doing it wrong, according to a new Stanford study.

This requires further clarification. What is it that we want to optimize? How do we know we want to optimize that?

Agreed! Makes me wonder if all these blogging platforms are solving problems or creating new ones. For every discerning reader who may be wise to not trust what they read, there are thousands of gullible ones who would believe anything they read just because it is written.

Just saying that these "feel like toys" is a very low-effort comment. Header-only libraries exist even if uncommon and they work fine when written properly.

If you actually use a header-only library and it fails to link properly or be used in a project with multiple compilation units, then that would be a bug in the header-only library worth discussing and fixing. That would be a good-effort and interesting comment.

> open source, means the source code is available, in my opinion.

Hard disagree because I have been in the open source arena for two decades and I have never seen any notable project using "open source" to mean "source code is available". A software whose source code is available is just "source available" but "open", "free", "libre" mean much more than just source code available. I am not making this up! Just look at the license terms of any open source project of repute.

"Source available" is not enough for me to use a software. If a software license forbids any field of endeavour (including but not limited to commercial activity), it is no longer "open" to me anymore. Sure the source is available but it is not open, it is not free, it is not libre because it discriminates against a field of endeavour.

When I make something open source I really mean "open" and any individual or organization should be able to use my software without any discrimination while agreeing to the terms and conditions set out in the license.

If I really want to forbid commercial activity, then I will choose a "noncommercial" (and thus non-open, non-free, non-libre) license.

Opensource has a specific definition and the definition includes:

> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

So if businesses cannot use it for commerical purpose, that's not open source literally by definition. It is not about what your line of thinking is. Words have meaning and "opensource" has a specific meaning.

If you want to talk about software that must not be used for commercial purpose, there is a specific word for it too and the word is "noncommercial" which is not the same thing as "opensource".

I don't see the parent comment as necessarily an entitlement. They are not demanding anything in particular from Homebrew project maintainers. They are informing us -- the readers -- about the analytics behavior in Homebrew so that we can make an informed decision about whether we should continue to use Homebrew or choose an alternative like macports or nix. It read more like a public service announcement to me.

The early PCs and BASIC provided such a simple and effective computing environment where any newbie could start reading the online manuals (known today as built-in manuals) that came with BASIC interpreter and start writing some simple code immediately into the integrated editor that also came with BASIC!

I think the loss of a simple, integrated and interactive programming environment like BASIC has been a tragedy. Is there anything like BASIC today that any child, secretary, or grandmother can pick up and learn with as little hassle as possible?

I don't know... The article does look like a veiled attempt at advertising their own community where they get to earn a $99 fee for every new registration. What I felt was in poor taste was that this motive of advertising and profit was hidden until the end of the article. Not calling it a hidden ad would be a stretch IMO.

But once the company locks me out, I would neither have screen sharing nor video calls nor the DM list. Isn't it better to just use Matrix which may have less features but those features I can rely on for a long time without the risk of being locked out?

The popularity of Discord always surprises me! It takes hard work and time to create an active community. Why put all that hard work and time into a corporate-controlled platform that can lock you out of it anytime they want? How do people feel ok taking such a big risk? Why not use an open protocol like Matrix (or IRC if you're savvy) to form your community?

> I’m also having affectionate memories of JavaScript and Python

I am afraid, things are equally messy in JavaScript and Python too. "X language isn't fun anymore" is exactly how I feel about X = JavaScript, X = Python, X = C++, X = Java and many other languages.

There was a time when I found Python and Js to be very fun languages. But recently the ecosystem has been becoming a mess. Build breakages on dependency upgrades are the biggest fun-killer IMHO.

Heck, there was a time when I found even Java to be fun. C++ too was fun in its early days. But every language keeps adding more syntax, more complexity and more ideas that deviate from the original design goals of these languages. These additions make the languages messy and the simple and characteristic ideas for which the languages were once loved get lost in all the complexity. I find it really disappointing. I really wish the languages preserved their original culture and philosophy.

For the never-ending and ever-increasing churn in all the languages I have gradually gone back to adopting Emacs Lisp and Common Lisp for all my personal programming needs. Common Lisp's standard is frozen in time, so for better or worse, I am protected from the constant churn I see in other languages. Emacs Lisp has a really good leadership that has been very wise to avoid adding additional complexity to the language. I wish the more modern languages were more reluctant in adding new complex ideas into the languages.

What did they do in the 1970s? Care to share more about it for people like me who do not know what exactly happened?

All I could find was this - https://en.wikipedia.org/wiki/Climate_change_in_France but this shows improvements beginning at 1990s and later.

> They aren’t terribly relevant to the situation where you just ate somewhere that does pay less than minimum wage.

Sorry for being obstuse but I still don't understand. How as a customer I would know whether the place where I ate at is paying less than minimum wage or not?

> Them having a bad day and mistreating you doesn't mean they should be condemned to poverty.

That's all good but why does this logic apply to the customers and not the business owners?

> Unless of course you think people who are bad servers don't deserve to make minimum wage.

Why should the responsibility of paying a bonus (a tip) to the server fall on the customer? Why shouldn't the business be held responsible for paying them the bonus? As someone from Europe, I find it difficult to wrap my head around the fact that it is somehow customer's responsibility to pay them a bonus/tip even if there has been a bad service. In my mind it should clearly be the responsibility of the business to pay them what they deserve.

> (def my-hash {:a 1 :b 2})

I don't know! That looks very unlispy. So much new syntax and inconsistent with the otherwise very uniform Lisp syntax.

The Racket alternative

> (define my-hash (make-hash)) > (hash-set! my-hash 'a 1) > (hash-set! my-hash 'b 2)

looks much much better to me!

Thanks for the reply. I do have some questions to understand how far vim-slime can go in providing a good lisp interaction environment. For instance,

1. Can I select an s-expression (along with all the nested s-expressions within it) and send it to the REPL? When I checked vim-slime I saw that it has no understanding of s-expressions. The onus of carefully selecting the s-expression and sending it to REPL relied on the user. If I selected what amounts to nonsense and send it to the REPL, vim-slime sends that nonsense for evaluation. vim-slime did not seem to help with these things. Is that your experience too?

2. Does vim-slime use the compiled functions for autocompletion/suggestions? SLIME and I think SLIMV too helps with autocompletion, shows the valid arguments of a function automatically in the status line, and such things as I type code. SLIME/SLIMV make use of the compiled functions to provide IDE like completion/suggestion features. Can vim-slime do this?

SLIMV or real SLIME do have key-bindings to send any s-expression the cursor is on, or send a top level form automatically and send it to the REPL. Seeing the valid arguments in the status line as I type code is useful for functions where it is easy to forget which argument goes first and which goes second. Just some of the many small features I rely on while using the real SLIME with Emacs. Can vim-slime do these too? When I checked vim-slime it could not do these things and it could not do a bunch of other things that I consider essential for lisp interaction.

https://github.com/jpalardy/vim-slime is a terrible SLIME to be honest! Wait! It is not even a SLIME. It just copies text from one text buffer and pastes it to another Vim buffer which is probably running a REPL. "Probably" because who knows what the target buffer is running. vim-slime does not care. This is not Superior Lisp Interaction Mode for $EDITOR (SLIME) in any way.

vim-slime does not connect to any Swank server. It does not understanding Lisp s-expressions. It would happily copies any random text into any random REPL and call it job done! Lisp interaction mode is much much more than just copying and pasting text around. A superior lisp interaction mode gives you live debugging, handling conditions, inspecting variables, navigating the stack frames, ... Vim-slime cannot do anything like this because, well, it is not SLIME! It just copy-pastes stuff around. Vim-slime is a disingenious and misleading name for a project that is not SLIME.

If you really want to use Vim, do yourself a favor and use https://github.com/kovisoft/slimv and experience a true Lisp interaction mode. It contains an actual Swank server and an actual Swank client that connects to the Swank server to provide an actual Lisp interaction mode in Vim just like SLIME does in Emacs!

Do you worry about correctness flaws in Julia that make it hard to write robust and correct code when you get deep into the weeds while developing libraries meant to be used by others or meant to interoperate with other libraries? It is not a problem with Julia but seems to be a problem in Julia's library ecosystem. It bothers me. Does it bother you?

> It also uses sizeof to calculate the size of an array which would be good in any language except C

It is a pretty standard and popular way of finding the size on an array. The only caveat is that the programmer really has to be sure that it really is an array and not a pointer to an array.

This does not look like SLIME. It seems to be just copying the text from one text buffer and pasting it to another Vim buffer which is running a REPL. That is not what SLIME is really! I can't even call this a poor imitation of SLIME because it is not SLIME in any sense of what SLIME is. There is no Swank server this connects to. There is no understanding of Lisp's s-expressions. It would happily copy any random text into any random REPL and call it job done! It is weird that they have chosen the name "SLIME" for vim-slime project when it is not SLIME in any way.

How do you use SLIME in Vim? Isn't SLIME written in Emacs Lisp which runs only in Emacs? Honest question how you could run an Emacs package in Vim?

I think the parent comment is suggesting that a comparison of CL vs. Clojure is more useful than the current comparison of CL vs. Racket.