nocman

> Now this feels like arguing semantics. Because multiple people are wrong, this makes them right? Sorry, no.

I did not say they were right. Effectively I said a lot of people use the term "open source" differently than you do, and that I didn't think the wording you chose to argue your case was going to be effective.

I understand the frustration.

> This is a solved problem, it was solved 15 years ago

I guess that depends on what problem you are referring to. In my experience, the use of the term "open source" to refer strictly to "source available" software is about as common as it ever has been.

> I’m going to complain about this, net positive effect be damned.

Well that's your choice, but in my opinion by doing so in the way you have in this thread, you are working against the goal of persuading people to use the term in the way you want it to be used.

> Basically, if there is no free will, there is no point in debating

But if there is no free will, you should not even try to stop someone from debating if there is a free will, because they have no choice but to debate it.

Of course I realize that if there is no free will you have no choice but to try to stop people from debating if there is a free will.

OK, I'm going to choose to stop going down this rabbit hole now.

> Nope. Sorry but you don’t get to hijack the term “open source”

The problem with this viewpoint is that the OSI is not the final arbiter of the English language.

Yes, the OSI has an "official definition" of what constitutes "open source" software, but there is a large group of people in the industry that equate the term "open source" with the concept of the source being available, and nothing more. You can shout "wrong, wrong, wrong!" all you want, but I doubt you are going to change many of those people's minds.

The Free Software Foundation has a similar problem with the term "free software".

The people making the definitions are generally passionate about those definitions (for good reasons, mostly, in my estimation). However, I don't think an approach that starts with "Sorry but you don't get to hijack the term" is going to have a net positive effect. If anything, it will probably have a negative effect.

I understand that some people don't see the value in face-to-face interaction with coworkers -- and I say this as someone who has worked in most scenarios (long-term remote, long-term full-time office, and partial remote). It obviously has more value for some than it does others. I actually prefer full-time remote, but I understand why some people don't like it.

For some people, face-to-face makes it easier for them to get to know co-workers and develop a solid working relationship with them. Also, those face-to-face interactions often result in benefits for the company, as you often do still end up talking about things related to work, and valuable ideas can be exchanged that would not otherwise have been. Even if you don't talk about work things, knowing your co-workers well can be a benefit to the company. Obviously there are cases where you don't want to know an abrasive person well, so it varies.

Your post sounds like you are saying in-office work is obsolete due to it being an "old-fashioned idea" (unless I am reading you wrong). If that is the case, I would caution against the possibility thinking newer is always better, because it clearly isn't always. Again, as I said, I prefer remote work, but I also understand why others don't. The same work model is not best for everyone in the world.

Your note taking, organizing and writing will have helped you retain a lot more info for a longer period of time. It wasn't wasted effort. Still, there is a such thing as "too much". Higher degrees of success are achieved by regularly evaluating where you are in the "too little" to "too much" spectrum.

No matter how you spin it, this makes the landing page very misleading.

Nobody cares about the "design" of a language when there is no implementation that fully realizes the design. Otherwise, anyone can say "my language is 100% compatible with clojure, but oh, yeah, the clojure compatibility part isn't fully implemented yet".

If your landing page said "jank's goal is to be 100% compatible with clojure", or "jank is designed to be 100% compatible with clojure (when fully implemented)" that would be fine. Right now the statement is just false, because right now, the language isn't 100% compatible with clojure.

I really think you should change the wording -- and I say that as someone genuinely interested in the project. I hope you achieve 100% clojure compatibility, that would be really cool. With the way things are worded now the first impression you are giving people is that the language implementation is way more complete than it is, which I believe will be a big negative for you in the long run.

I agree whole-heartedly with OP's use of "braces around variable names where they aren’t strictly needed". I have two reasons. First, consistency is nice. Second, they aren't needed now, but invariably you will end up coming back and adding to the script, and will end up needing them.

OK, maybe I have 3 [I mean 4] reasons. 3) if you always put the braces in, it won't break your script when they aren't required. However, if you don't put the braces in when they are required. it will break your script. 4) often putting the braces in when they are not required makes the script easier for me to read. I often use spacing that is not required for the same reason.

I'm not saying I never break my own "rules" (they are really more guidelines than rules). You will find variable names used in my shell scripts that have no surrounding braces, but I probably use more of the "unnecessary" ones than a lot of people do. And yes, I'm aware that sometimes not having them makes me less consistent. Everything has a balance, people just differ on what style provides the balance they prefer.

> Sometimes the point is just having it possible. Sometimes I need to get that last bit of performance out of some code

I'm talking about complexity beyond using a small subset of C++ features, things like template metaprogramming (but not limited to that).

> If your performance requirements are more in the scripted range then C++ will seem like overkill. I often use python for quick and dirty tools, however every other time I end up rewriting things in C++ because something that should finish almost instantly takes half an hour.

I have a wide range of requirements depending on what I am working on. I can still drop down to a C or C++ level if I need to, but if I do use C++ it will only be a limited subset that minimizes complexity.

Also, you imply that Lisp and Scheme-like languages are limited to performance on par with Python or other so-called "scripting languages". There are languages in that vein that can perform very close to C's performance (Gambit Scheme being one such example). Often instead of rewriting in a lower-level language, you can use optimizations in the language to improve performance. Of course you can also just rewrite smaller portions of code in C or C++ and call that code from another language.

I'm not someone who just dabbled in C++ for a little while and gave up. I have decades of experience with it. I wanted to use it beyond "C plus a little extra", but I found that the further from a C-like subset I went the more incidental complexity I had to deal with, and in the end the benefits I was looking for just never materialized.

My opinion is similar to others in this thread. The complexity you are required to manage in order to push the limits of C++ makes doing so not worth it. There are far too many ways it can bite you, and the benefits you gain by moving beyond a small subset of C++'s capabilities were not worth the hassle for me.

I really wanted them to be worth it, and spent years trying to make it worth it. I guess in the long run it was worth the time spent, because it caused me to explore other possibilities that I might not otherwise have considered (in particular, Lisp and Scheme-like languages, which I doubt I would have otherwise given a second look -- they were just "weird languages that we spent a couple of weeks looking at in college - and oh, yeah what's up with all those freaking parentheses?").

I'm sure the people who do the competing enjoy it, but I can't imagine it being something any large group of people would enjoy watching.

kinda funny if you spam click it also.

> To use anything else (than JavaSE without heavy deps.) on the server is madness.

That's a terribly broad generalization. There are multiple other options that are entirely sane.

You offer plenty of criticism for using and/or generating makefiles, but I can't find any place in the discussion where you suggest an alternative.

So what is your solution for building large projects?

For some reason I thought (because of the title) this article was going to be about implementing a Lisp dialect in vimscript.

I thought, wow, that's impressively masochistic!

:D

> So sorry, there is no ransoming. Just a bit of old fashioned fraud, and not on the part of Tesla.

Actually, it's just a bit of old fashioned stupidity on the part of Tesla (or, at least, on the part of one of Tesla's employees).

They made the mistake when the car was owned by someone else (in fact, two someone elses ago). It would cost them basically nothing to just leave it alone, and instead they've gained a huge pile of ill will -- not only for the current owner of the car, but an internet's worth of customers and potential customers. And saying they will "fix" what they "fixed" for $4500 just makes them look even more like jerks.

Really bad move on Tesla's part.

Well, you NIP'd that in the IPL bud.

I've only used big iron in anger (as part of my company's "ways of doing things" - and all of it unexciting parts of my job, and many years ago). I was not aware of said Nucleus before you brought it up. So I guess today I learned something. Cheers!

As is often the case, the mouseover text on that XKCD just makes the comic!

Don't you mean "the Nucleus of the Core of the Kernel"? :-D

'cause we're all in the mood for a movie, and we'll be rewinding all night.

> He is referring to a firing.

How do you know that? OP doesn't say whether or not other people were let go at the same time also. It could be either.

Nope. I earnestly clicked the link wondering how in the world Billy Joel was keeping Blockbuster Video alive. LOL.

Just because someone suggests a way to work around a problem doesn't mean that they aren't also annoyed by the problem.

There are some problems you do not have a viable way to attack at the root, and you just have to deal with them. Often other people control the thing you would have to change, and will not be persuaded to do it your way.

I understand the desire to not have to learn something just to be able to remove an annoyance, but isn't having that option better than not being able to remove the annoyance at all?

I'm not being at all obtuse, you just don't agree with me.

Also, if you don't want to use "git reflog" at all for "undoing", you could undo your previous commit with:

  git reset HEAD^

Or if you also want to discard the changes you made to files in the repo at the same time:

  git reset HEAD^ --hard

But use the --hard option wisely. Be sure you really don't want to keep any of the changes you made (or that you have already saved them elsewhere before running it).

You have made my point for me.

There is a minimum level of knowledge you need to know to use git. It is not as straightforward as, say a simple text editor. The problem git is solving is more complex than that, and therefore understanding how to use it requires investing a significant amount of time in learning how it works.

If I was going to go back to my previous commit, I would use "git reset" to go back to the commit prior to the one I just committed. The only reason to use "git reflog" as part of that process is to see which commit was prior to the one you are working with now (in order to pass it to "git reset" to undo the changes).

> "Undo" is a reasonable choice if you barely understand what git is for and "reflog" is not.

But "git reflog" is not an undo mechanism. It can be used to determine a commit SHA to reset to (in order to 'undo' the last commit with "git reset"), but it is used for a bunch of other things also. It is appropriately named for what it does.

If you "barely understand what git is for" then the solution is to learn the minimum you need about git in order to use it effectively. I am not talking about mastering git, that's an entirely different topic. I'm talking about basic-level knowledge. Again, the required initial time investment for git is significant, but in my opinion it is worth it.

If you don't feel the investment is worth it, then you should use something else.

> How is "reflog" the correct and intuitive choice for "undo"? Was there something I wasn't understanding? No, I'm just supposed to accept that.

Actually your initial intuition was correct. There are things you obviously don't understand about git. "reflog" is short for reference log. As "git help reflog" will tell you:

  Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.

It isn't arcane. It's perfectly logical choice for what the "git reflog" comand does, as explained in the man page: "This command manages the information recorded in the reflogs."

Now if you don't know what a reflog is, you will be confused by this. But the solution to that is for you to learn what a reflog is. And yes, in order to use git well you need to have at least a rudimentary understanding of how it works.

I know that some people do find git hard to understand. Often that is because they want it to work a different way than it does. But git is a fairly complex tool designed to solve a very complex problem. It does an outstanding job of doing what it was designed to do. However, if you are not willing to invest the time in understanding git to a minimal level (and many people aren't), you will find it to be confusing.

There is no need for "sanity" to "come to the naming of commands" for git. The commands already have sane names. But if you don't know what those names mean, it will seem to you as if they are in a foreign language. Most of the confusion people have with git is due to them having an insufficient level of knowledge of how it works. Again, if you want to use git well, you have to gain that minimal knowledge . If you are not willing to do that, then you should either become willing or choose to use some other version control program that is more to your liking.

No. (edited: by that I mean you are not the only one)

And after wasting enough time to find out what it actually looks like, it left me with this opinion: The "Simple Checkbox" they started with is 10,000 times better - although it seems silly to me to have one checkbox be the only thing on the screen (usually they occur on the left of items in a list).

It's not just you. :-D

Because it is a sped-up/chipmunked version of Roger Miller's "Whistle Stop". And Roger Miller was freaking awesome!

( https://youtu.be/JPt1n2AdQd4?t=35 )