Mostly solo dev. I only use branches when working with some colleagues who are "branchists". It's not that I don't understand branches, but they always look unnecessarily cumbersome to me. The worst offenders are "feature branches"... I want my tests to try the program with/without the new feature and compare the results. Thus any feature is better implemented in the master branch, and activated using a flag. No need for a branch. If your feature is hidden in another branch, how can you test it? Does your test suite run git commands?
Do you push your code to a repository where you have some CI set up? Or is it just local? If it's the latter and you just run tests on the command line then yea maybe you don't need branches. On the other hand I find branches can be useful if I have a larger refactor going on and I'm not too sure what it's going to look like in the end. Then I can keep it on a branch and compare it to "last known stable commit," and if something else comes up that needs to be fixed right away I can put my larger refactor on hold and fix it, and come back to the larger refactor.
“Last night somebody broke into my apartment and replaced everything with exact duplicates... When I pointed it out to my roommate, he said, "Do I know you?”
― Steven Wright
It's not trained for it, because that use case is handled differently. It would be mostly a waste of time to train the concept compared to other things you want to achieve. Instead you put things you don't want in the negative prompt. This example doesn't expose the option, but you can try it here for a different model: https://huggingface.co/spaces/gokaygokay/Kolors
Set the seed to 0 and prompt to "man in a loud shirt" - you get flowers. Sweet the negative prompt to "floral shirt" - no not flowers.
Sentence processors can definitely understand negation, (any non-trivial LLM can) but it would be a waste of time to train that in the image generators -vs- making other ideas better.
I did mean AI's in general, so I have edited my original post.
> That’s what negative prompt is for.
This is what I mean by it "not understanding negations" You need whole separate prompt, just to say you want e.g. "ramen without egg" instead of just saying it in a single prompt that it understands.
They generally do. It is difficult to differentiate "negative tokens don't do that" and "prompt adherence is shaky in general".
It's fully possible that the image model draws eggs in ramen but it doesn't know that the egg is an egg and therefore any attempts to interact with it via the egg token are futile. Generally speaking though thing:-1 should reduce the presence of thing for well understood concepts. It's a better tool on second pass alterations of an image.
You're not correct about AIs in general. Both chat LLM models and sentence embeddings can handle negation just fine. (Ask any chat "what clothes would a person wear if they weren't wearing a hat") Here it was simply not trained for that purpose. Maybe it wasn't worth it, maybe the creators thought that the negative prompt is enough, maybe the time was better spent on other examples. They way, it's not AIs in general, and it's not a tech limitation.
AIs are able to understand negations, just ask an LLM a question. Text-to-image models are the ones that struggle the most with this, they usually do not have a very nuanced understanding of text.
This is really cool, but I don't think this is very useful.
In my opinion: if you can use vim, you can probably code, or at least figure it out without too much trouble. If you can code, then you don't need a spreadsheet. You can just write a program to crunch the numbers, or produce a report etc.
Excel is so popular, because it is a way for non-coders to crunch a bunch of numbers in a relatively easy way. And the best way to get the answers that they are getting out of the spreadsheet is to write code. But because they can't code, they have to use a spreadsheet.
If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
You could also make the "speed" argument (just a quick calculation) for spreadsheets, but in that case, I find something like a python REPL just as quick, and still better anyway.
While vi might be a code editor first and foremost, not all vi users are coders. There are copy writers, academic and literature, having a need for fast and focussed touch typing (George R. R. Martin comes to mind as prominent WordStar user). The entire point of SGML/XML/HTML markup is to be able to create rich text documents without binary formats and special editors; this is also the case with Wiki syntaxes like markdown, which have been around since long before John Gruber's original Markdown.PL and are directly supported as a shortref customisation in SGML, from 1986, BTW.
Conversely, even if you are a coder, classic spreadsheets are extremely useful for any type of ad-hoc reproducible calculation (such as for taxes or other personal or business finance stuff). You really should check out spreadsheets if you haven't already; the point is that you can cross-reference cell values and copy/paste with relative cell positions to create large calculation tables/matrices, then update base values and perform "what-if" analyses, etc. etc. Using cell formulas is more like a logical programming language environment. I've used it for all kinds of reports apart from financials (benchmarks, construction/project planning, even a Tic Tac Toe game in school out of boredom).
I don't disagree with your first paragraph, but I don't think it is relevant to what I was saying.
> Conversely, even if you are a coder, classic spreadsheets are extremely useful for any type of ad-hoc reproducible calculation
Again, I still feel like code is the ideal solution to "ad-hoc reproducible calculations"
> the point is that you can cross-reference cell values and copy/paste with relative cell positions to create large calculation tables/matrices, then update base values and perform "what-if" analyses, etc. etc.
I still don't see how you can't do that with code, nor what the spreadsheet is doing that code can't.
> I've used it for all kinds of reports apart from financials (benchmarks, construction/project planning, even a Tic Tac Toe game in school out of boredom).
Sure. It has been proven that excel is Turing complete. But I'd rather use a programming language (a tool that was literally designed for the purpose of writing code), than a clunky spreadsheet. Both can get the job done, I never denied that. But I still don't see the value that the spreadsheet brings over custom code written to solve the exact same problem.
I'd love to hear what specifically makes you call spreadsheets "clunky"? (Personally I find spreadsheets to be quite elegant, a table adapts easily to WIMP [https://en.wikipedia.org/wiki/WIMP_(computing)]. E.g., in contrast to say the Bézier curve interface in Illustrator, which I wouldn't ask for explanation in being called clunky, because drawing curves does not adapt easily to WIMP for example.)
> Again, I still feel like code is the ideal solution to "ad-hoc reproducible calculations"
I am a developer and I do my personal budgeting on a spreadsheet. It was easier to setup and maintain, and follows my process better than the personal finance software I have used before. Could I have made a little program for this? Sure, but it would be time consuming and I have better projects to spend my time on.
Let me tell you the story of how i came to love and use sc-im instead of my own solution.
Multi-country taxes are too much fun. Every dollar/GBP amount needs to be converted to the other currency for taxes in that country.
I originally did this in libre office but I got annoyed at it and wrote a markdown pipeline to produce PDFs for my accountants.
I would do data entry in CSV and wrote a CSV to markdown converter. Along the way I wrote a simple CSV formula language with just a couple of functions that would do column level operations e.g. =MUL(C, E) to multiply columns C and E.
This worked pretty well, and I could make a small directory of sorted markdown files to assemble, and a Makefile to transform the CSV+formula files to flat CSVs.
But CSV input was kind of annoying and my formula language wasn't easy to extend, or very nice. So I jumped at sc-im which can directly output markdown tables.
Anyway, I highly recommend sc-im, the .sc files are a fine replacement for my custom solution and I haven't looked back (and taxes are coming again soon!)
I am a counter example to your assessment. I can definetly code, but I wip up spreadsheets often.
> If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
Sharing information with non-coders could be an obvious one. I could have done a database with my wife's sewing patterns collection, of which she has ~300. Instead, I did a spreadsheet in google docs, which she's very familiar with. Told her how to enter data there (4 fields, name, file, tags and picture) and there's a couple tabs that allow her to filter things out, etc. Then she can do whatever she wants with it, like using conditional formatting to make dress patterns red. It was done in 2-3 hours, and she got exactly what she wanted.
I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users. We did implement a database for this particular one for the heavy algorithmic part, but a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
> Sharing information with non-coders could be an obvious one.
You can do the exact same thing with code. You can still output reports and diagrams, and literally anything the "customer/user" wants.
> I could have done a database with my wife's sewing patterns collection...
Your example is a good one. I didn't think of images.
> It was done in 2-3 hours, and she got exactly what she wanted.
Fair enough. A spreadsheet was probably the right tool for the job in this case. But if she ever wanted more features, and the complexity increased, I don't know if it still would be.
> I worked in a place where both the input and output was spreadsheets, and the users were spreadsheet users.
Okay, but should they have been? Would custom software not have been the better solution?
> a lot of the business logic (e.g. initial data validation, final presentation of the results) lived on the spreadsheets themselves.
When I think of "business logic", "data validation", and "final presentation", a spreadsheet is one of the last tools I'd reach for.
> Another interesting one is data-to-visual time. Unless you happen to be proficient in a particular area of programming (e.g. front programming with proficiency in something like D3, or R programmer) getting decent graphs out of data is a chore when going the programming route. With spreadsheets, you put the columns and get the graphs essentially for free.
I also disagree with this. I am very much a back-end developer. But using something like GNUplot or a library like matplotlib is pretty easy for outputting a nice looking graph from tabular data.
> To me spreadsheets are just another tool in the toolbox; they are appropriate for some tasks. They can definitely be misused and abused. Knowing which occasion is which is where experience comes in.
I agree with this. But I guess the difference is I can think of almost no circumstances where it's the better tool for a coder.
You forgot one thing: data entry. It is far more convenient to type tabular data in a spreadsheet app than in a REPL. I use it for simple SQL data, too. As Python coder I use visidata. Provides also fast and convenient aggregations etc.
And, btw, if you search for "distraction free writing",you will find that even some non-coders use vim.
I've never really had a problem entering data into CSV file or database, but I will concede that it is even easier to enter the data via a spreadsheet.
However, I still think custom software (with proper UI for input if necessary) is the better way of dealing with the actual solution that a spreadsheet is ultimately trying to solve.
> If there is a use case for spreadsheets that is not better served by some real code, I'm interested to hear what it is.
Think of spreadsheets as a convention-over-configuration low-code environment with a tightly coupled GUI for spinning up run-almost-anywhere apps that non-coders can modify. One of the few low-code environments that I actually like.
I'm a solopreneur whose SaaS product I coded from scratch. I love GPPLs, but I also create spreadsheets all the time.
Sometimes that's because of the stage of an idea: There's a new process you've discovered you need, but you don't have time to invest in building/buying/learning a tailor-made solution.
A case in point is a business overview dashboard I built to keep an eye on the metrics I care about. It pulls data from disparate sources using Power Query, which is built into Excel and can pull from databases, APIs, CSVs, etc. There's no hosting infra and no new monthly fee as I already had the Excel license.
Another nice thing about spreadsheets is that today, they're multi-user and real-time collaborative. You can send someone a link and both edit an Excel or Google Docs spreadsheet in the browser with very low ceremony. And if they're on a power user, they can modify the formulas themselves. That's a bad thing for some use cases but a truly great thing for others.
The ubiquity, the local-first option, the tightly coupled GUI, the widely known syntax...those things make spreadsheets very attractive for certain types of projects.
For others, building an app is the right answer. They both have a place.
Making a spreadsheet that does a variety of calculations, displays graphs, live updates, is share-able, editable via web and mobile, can be embedded in technical documents and presentations is all free with a spreadsheet. Your comment trying to address the speed argument, replacing with a "python REPL" is difficult to take seriously. Spreadsheets are order of magnitude faster, and that speed advantage scales from the simplest of spreadsheets to the most complex (i.e., just summing a column of data will be maybe 10 times faster in a spreadsheet than a python REPL [although both are trivially fast for this use case], and doing all of the above listed features would be months to program relative to free for the spreadsheet).
"If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail." [1]
While you can solve a lot of problems with code, code might not be the best way to solve some problems.
I want to type in some data, mix it up, explore, maybe make a quick graph, get some stats, decide if I need to make more calculations. By the time you decide on what tools to use and run your pip install or whatever, I'd be long done.
Conversely, I have seen spreadsheets used for a lot of things that they shouldn't be.
i am able to program but hell no i will start to crunch numbers programmatically unless it's something a basic spreadsheet can't do. i use spreadsheets exactly because i don't need to code and create something from scratch.
but while this is not for me (no interest in learning vim), i'm pretty sure many other people will find this useful
VisiCalc - the first spreadsheet - was entirely text based and people found it useful enough that it exploded in popularity and was very successful on the Apple ][ until the advent of the IBM PC when Lotus 1-2-3 came and ate its lunch.
Just because we have made progress since the last one doesn't mean that _this_ time it will be magically different.
So what makes you think this will be any different?
Keep in mind that each hype cycle was started by a leap in progress, so you can't say this time it is different because we made a big leap in progress.
