I don't think Daniel's point is that Chat is generically a clunky UI and therefore Cursor cannot possibly exist. I think he's saying that to fully specify what a given computer program should do, you have to provide all kinds of details, and human language is too compressed and too sloppy to always include those details. For example, you might say "make a logon screen" but there are an infinite number of ways this could be done and until you answer a lot of questions you may not get what you want.
If you asked me two or three years ago I would have strongly agreed with this theory. I used to point out that every line of code was a decision made by a programmer and that programming languages were just better ways to convey all those decisions than human language because they eliminated ambiguity and were much terser.
I changed my mind when I saw how LLMs work. They tend to fill in the ambiguity with good defaults that are somewhere between "how everybody does it" and "how a reasonably bright junior programmer would do it".
So you say "give me a log on screen" and you get something pretty normal with Username and Password and a decent UI and some decent color choices and it works fine.
If you wanted to provide more details, you could tell it to use the background color #f9f9f9, but a part of what surprised my and caused me to change my mind on this matter was that you could also leave that out and you wouldn't get an error; you wouldn't get white text on white background; you would get a decent color that might be #f9f9f9 or might be #a1a1a1 but you saved a lot of time by not thinking about that level of detail and you got a good result.
Yeah, and in fact this is about the best-case scenario in many ways: "good defaults" that get you approximately where you want to be, with a way to update when those defaults aren't what you want.
Right now we have a ton of AI/ML/LLM folks working on this first clear challenge: better models that generate better defaults, which is great—but also will never solve the problem 100%, which is the second, less-clear challenge: there will always be times you don't want the defaults, especially as your requests become more and more high-level. It's the MS Word challenge reconstituted in the age of LLMs: everyone wants 20% of what's in Word, but it's not the same 20%. The good defaults are good except for that 20% you want to be non-default.
So there need to be ways to say "I want <this non-default thing>". Sometimes chat is enough for that, like when you can ask for a different background color. But sometimes it's really not! This is especially true when the things you want are not always obvious from limited observations of the program's behavior—where even just finding out that the "good default" isn't what you want can be hard.
Too few people are working on this latter challenge, IMO. (Full disclosure: I am one of them.)
Which no one argues about really. But writing code was never the issue of software project. And if you open any books about software engineering, there’s barely any mention of coding. The issue is the process of finding what code to write and where to put it in a practical and efficient way.
In your example, the issue is not with writing the logon screen (You can find several example on github and a lot of css frameworks have form snippets). The issue is making sure that it works and integrate well with the rest of the project, as well as being easy to maintain.
Disclaimer: I'm a complete noob about the history of the region and the languages involved.
I just figured out the best way to get an answer on the web is to post a wrong one first, so I went 5 minutes into the subject on Wikipedia and what I've concluded is that maybe it's actually the other way around.
Poland is like "Land of Polans" which were the original tribe of the region.
The Ш letter seems it is a prefix that comes from Hebrew, so maybe, Шпола also refers to Polans in some way.
I must emphasize again that this can be completely wrong.
The name "polans" derives from the word "pole", which simply means "field". There were actually several different groups of Slavs who were known as "polans", all named because of where they settled. One of them did indeed found Poland. But there were also (different) polans in what is now Ukraine - indeed, they were the dominant group, as Kyiv was their city.
In any case, "pol" in the placename can simply refer to a field directly. Or even to something else; in case of Shpola, the local legend is that it was named after the guy who first settled there.
I don't know why everybody thinks Microsoft Word doesn't have Reveal Codes. They have it; it's called Reveal Formatting; it has mostly been there since version 1.0 which I remember installing from 100 floppy disks in college in 1989.
Word's "Reveal Formatting" just shows tabs, spaces, and carriage returns as distinct symbols iirc.
Wordperfect's "Show Codes" tells you every attribute and layout change inline.
For example, if bolded some text, Word would just bold it. Wordperfect would insert a symbol like [bold] and the text would be plain, instead of rendering it. Removing the code symbol would change the attribute from the text. This allowed you do to format documents for printing on a system that couldn't handle displaying them fully formatted interactively.
I remember trying this when my dad bought a Windows PC with Word 2.0 (or something), so I could use that instead of his work laptop with WordPerfect. I do remember finding it really didn't work as well, though I don't remember exactly why any more.
This isn't a great response, I know. It's just a data point for the theory that Word and WordPerfect are comparable in this respect.
(This is going back so long ago now. I was still at school! Maybe the problem was that you still had to interact with the GUI view to fix things? So you could still end up with the usual weird Word stuff, but no way to fix it, because you couldn't get right in there and just manually shuffle the codes around like you could with WP.)
While MS Word does have Reveal Formatting, it is really not a good replacement for Reveal Codes. It's a clunky way to see isolated formating for a short portion of text. For example, how to search for all places in the text for a font change, or margin change, or section format change. It's difficult to also show where certain formatting starts or stops.
Under WP, you can instantly scan the entire document looking for those changes. Not so with MS Word. That being said, RF is better to compare 2 sections of text to immediately show their differences.
A member of that team told me that for much of the project the implementation of the function to calculate the height of a line of text, which is a very complication operation involving fonts, sub- and super-scripts, etc., was implemented as "return 12;" (that was the entire body of the function) and it was marked as "DONE". With a bug of course but we can fix the bugs later
The older versions are also not literal dumps. They're binary "dumps" of the object tree in memory, yes, in a sense that you walk the tree and write it out. This is bad because your in-memory object tree then effectively defines the format, and it's not spec'd otherwise, which makes portability that much harder, especially for a closed-source application where you can't see code. But it's a very different problem.
FWIW, old Office documents were actually CFBF (Compound File Binary Format) files - think of it as FAT-in-a-file, allowing for multiple independent streams inside, with transactions. This was very commonly used on Windows in the OLE/COM era, because it was the underlying format for OLE Structured Storage. It's what allowed a Word document to embed another arbitrary document in an extensible way. The underlying data in the streams within CFBF was a loose object graph dump.
It all makes a lot of sense when you have your OLE glasses firmly on - it's basically a natural design that follows if your world consists of OLE objects and interactions between them. Look up IStorage and IStream to see what I mean.
The side effect of all this, however, is that the data inside an old Office file is not laid out in a logical way - streams consist of non-sequential interleaved blocks in a seemingly random order (depending on what was written when), some blocks may contain garbage data, and so on. So it's very difficult to reverse engineer, which is why it took so long back in the day, and the results were often unreliable.
> FWIW, old Office documents were actually CFBF (Compound File Binary Format) files
That's actually the "new" binary formats. The usage of CFBF seems to have been introduced in Office 4.2 (at least Excel 5.0 is the first Excel version to use them, it's hard to find information about the old Word document file formats).
> The side effect of all this, however, is that the data inside an old Office file is not laid out in a logical way - streams consist of non-sequential interleaved blocks in a seemingly random order (depending on what was written when), some blocks may contain garbage data, and so on. So it's very difficult to reverse engineer, which is why it took so long back in the day, and the results were often unreliable.
I don't believe the OLE compound file format has ever been much of an effort to reverse engineer. But the CFBF based Office documents are also basically just blobs of the older binary formats saved in a more structured way. The issues with Office documents have always been a question about their sheer complexity combined with their tight coupling to the internals of the Office programs. This still shines through in the OOXML formats which contains lots of stuff like "position something the way it was done in Word 5.0".
Sorry, Prashant, you lost track of the plot of the story somewhere along the way.
(creator of FogBugz, here)
FogBugz won and Jira won, but they were playing different games.
I wanted to make software development better for programmers. When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000). There was almost no thought around how software should be developed. Companies that scored high on the Joel Test[1] were almost unheard of.
The LAST thing I wanted to do was make another tool of oppression for management to impose gantt charts and deadlines and strict rules about who has to sign off on things.
I set out to make software development better for programmers by blogging[2] and by building a company that would be a great place to work[3].
In 2000 the only way to do that was to bootstrap it. With a team of four people we couldn't build anything complicated. We started with bug tracking software because at least we could touch one aspect of programmers' lives with our philosophy.
FogBugz was designed for smaller collegial teams of people that wanted to work together effectively and needed a clean and simple way to track issues using the smart workflows that small, professional teams like to use.
It was remarkably successful and profitable from 2000 to today. We've never stopped working on improving it, but we also have never abandoned the market of small collegial teams of smart people.
By contrast, Jira was designed as "Enterprise Software" with features to help managers impose specific workflows on teams. Selling Enterprise software is a lovely, profitable business and Atlassian has great success selling to large organizations who ignore FogBugz, but it's the opposite of what I wanted to do. Anyway Atlassian is going public with this enterprise software, good for them, I'm sure they're going to enjoy their well-earned private jets.
But FogBugz was the means, not the ends, and at Fog Creek our ambition was not to be the world's greatest bug tracker software company, it was to fix things for developers. So we kept plugging away at other ideas. Some of them were kinda dumb. Some were moderate successes.
Two of them, Stack Overflow and Trello, were huge hits and spun off into separate companies. Stack Overflow, thanks to Jeff Atwood's inspired leadership, has had more impact on making software development better for programmers than any bug tracker ever will. Trello has grown as popular in three years as Jira grew in 15 years.[4]
Neither of them would have been possible if we didn't have the cash cow of steady FogBugz profits. That's what bootstrapping is, folks! You build one thing and use it to build a bigger thing.
In the meantime I think the world has figured out that programmers are writing the script for the future that everybody is going to live in, so conditions have gotten better. In big cities employers are falling over themselves to invent new ways to pamper and delight their programmer employees, with the massages and the sushis and the dog yoga. We programmers built ourselves hundreds of amazing tools, from github to npm to ci tools, build tools, IDEs, code refactorers, etc. etc. that make programming a million times better than it was in 2000, and bug tracking is just a slice of that pie and not a particularly important or interesting one.
But that said, FogBugz is still very popular and very profitable and thousands of teams use it every day, and we're still reinvesting those profits in making it better and in developing new products to make the world better for developers, and even though it doesn't support pointy-haired micro-managers and doesn't allow you to create a custom workflow requiring that a VP-or-higher sign off on bug reports, there are still small, collegial teams of smart developers who have figured out that this is how they want to work.
You may have arrived at this view now, but it isn't believable that you never saw them as direct competition with you.
For example http://www.joelonsoftware.com/items/2009/07/20.html makes it clear that you were adding features so that people wouldn't have to switch to "THE AUSTRALIANS". Which is a pretty clear reference to Atlassian.
FogBugz 7.0 will include a long list of simple
improvements that will make life dramatically
easier for people trying to get things done,
especially when they want to do things just a wee
bit differently than we do here in the Land of the
Fog. Every little feature will be a delight for
somebody, especially that person who keeps
emailing us because he can't believe that the
feature he wants which is obviously only six lines
of code hasn't been implemented in FogBugz 1.0,
2.0, 3.0, 4.0, "4.5", or 6.0, and if we don't get
it soon he JUST MIGHT HAVE TO GO OVER TO THE
AUSTRALIANS.
That reads like he's making fun of the idea that he's competing with Atlassian, not that he's existentially terrified of competing with Atlassian.
A compelling theory, but the Inc article he wrote in 2009 pretty clearly states that he considers them direct competition and laid out a plan to beat them.
And now the plugins are gone :-( With the new GUI they do not work anymore. I was so excited when the plugins were released, it's a great SDK and we were quickly able to write two plugins that we really needed
I have at times used then-current versions of Fogbugz and JIRA over the past 15 years, and I remember the dichotomy pretty much like Joel lays it out.
I used Fogbugz on small teams, where we didn't have a dedicated person to do things like administer the bug tracker (and where the programmers chose their own issue tracker). When I saw JIRA, it would usually be because there were a lot of layers of management above the programming team (and a need for lots of reports and charts to go into presentation slides), or because the programmers were offshore and not known personally.
That is just one anecdata point, of course. But I think it was always pretty obvious that the two products had completely different philosophies -- and also that they still did compete to a good extent, because after all they are both issue trackers for software development (at least primarily; I guess JIRA also aspires to track issues building your airplane and whatnot).
If those were the only two bug trackers that existed, I myself would choose JIRA if I had somebody else to set up and run it, and Fobugz if I had to do it myself.
"There was almost no thought around how software should be developed."
Really, Joel? So all the various software methodologies of the seventies and eighties, all the CASE tools of the nineties, Extreme Programming etc etc etc - all of this does somehow not count as "thought on how software should be developed"?!
He is not talking about software development methodologies, he is talking about the role of people (mostly developers) in the software development process.
If you think the software methodologies of Olden Times did not consider the role of people in the software development process you are mistaken.
They might seem archaic (and even wrong) when we look at them today, but still: smart people put a lot of thought into the methods, they were hotly debated among professionals, books were written, and consultants made money teaching and preaching them.
There have always been people who thought about how to make software development better, but there were far fewer of them, both in software and in management. Relative to what we have now, I think it's absolutely fair to say that there was almost no thought about it.
Even ten years ago I was convincing my co-workers and manager that we should be able to run our build without human intervention; today I would not believe you if you told me your team had that problem, let alone that people disagreed it was a problem.
wow, $33,000 15 years ago? That really puts a spin on me making $36,000 6 months ago, working in 4 languages and 2 platforms to build a really complicated SPA web app and mac flash content player system. Glad I got out of that job!
From my own personal experience, things weren't bad in the late 90s up to the point of the .com crash. Starting salaries in valley were $45k-$55k. There was a lot of competition for strong candidates, and working conditions were pretty decent. I do commend Spolsky for providing good working conditions in a market like NYC where the current trend seems to be to jam as many people in a space as possible.
as others pointed out, 2000 is when he founded Fog Creek, not when he started programming. He was in MS when Excel was still competing against Lotus, so that salary is likely from the '90s.
"When I started creating Fog Creek Software in 2000 programmers were treated like typists. They were not paid very well (my starting salary was $33,000)."
OK someone has to call bullshit on this. I started as a lowly software engineer straight out of school at the same time. I started at 70K (east cost, not NY). You lost me right at the beginning there and any desire I might have had to go through your wall of text evaporated immediately.
It's fairly sad that the "script for the future" is (partly) being written by people who consider a mere 665 words a "wall of text" that is OK to comment on, but apparently too long to read.
The comment was on the preposterous claim that programmers were treated as "typists" around the year 2000. It's as if dot.com boom has just been collectively erased from all the downvoters' memories.
That sentence construction certainly implied otherwise. Even disregarding the part about starting salaries, the implication that programmers were treated as "typists" circa year 2000 is preposterous. This is around the height of the first dot.com boom and tales of extravagant programmer salaries was already legend. Starting his argument with such a patently absurd claim just discredits everything else he says later on.
it is over 100 degrees outside, the world is round.
so does that mean if you don't agree with me that it's hot out where i live at this point in time and space that you don't agree that the world is round?
opportunity is different for different people in different places at different times. No need to be so flippant because he relayed his experience with you.
starting salary of 70k is pretty darn lucky without experience, many developers started out much lower than that and they still do. The point is the corporate attitude towards developers has changed greatly since 2000; from my view point i agree completely.
try starting out making 18k a year and then come post how much you feel valued.
I don't know why people keep doing this startup every two months. Every two months somebody tries it and then discovers why it doesn't work.
For almost all the smaller buildings in New York (non-professionally managed), which is where you see these middlemen brokers:
* The brokers are given an exclusive by the landlords because the landlords are not professionals and often not in New York City. They don't want to do any work, they want the brokers to do the work of listing the apartment, showing the apartment, and checking the qualifications of the tenant.
* The landlord has to give the broker an exclusive otherwise the broker won't do the work, because the broker needs to get paid.
* Although the broker fee (normally 15% of first year rent) seems expensive and even extortionate to the typical fresh college grad renting their first apartment, the brokers as a whole are not making very much money, because they have to do an awful lot of work to get the exclusives (marketing themselves to landlords, so to speak) and an awful lot of work to coordinate keys, show apartments, etc. It is easy to see this because there is massive turnover in the broker business and almost all of the rental brokers you see in New York charging "extortionate" fees are, for the most part, broke.
* Which is why they seem so slimy: they're kinda desperate.
* A ton of apartments in New York are still under some form of rent control, especially the cheap ones in small buildings that kids want. That means that the maximum rent is set by law. So even if a tenant MIGHT be willing to pay a higher rent if they didn't have to pay the brokerage fee, they can't. The landlord of a $1800 rent stabilized apartment is going to get $1800/month whether they use a broker or not. So for this landlord, the broker is paid for by the tenant, and might as well be free. Considering how much work they do, and how much they charge, zero, it's a great deal for the landlord.
So every time one of these fresh-eyed college grads shows up in New York, decides that the rental brokers are making bank and need to be disintermediated, and writes an App that will Connect the Landlord Directly to the Tenant, no landlords sign up for it. The bottom line is that the brokerage function is not ripe for disruption because, slimy as it seems, there's just not that much money being made.
Great points -- once upon a time my co-founder came up with an interesting theory that the rental brokerage industry is a NET LOSS for the brokers, and the only reason it works is attrition.
More formally, if you assign a reasonable hourly wage for a real estate agent, say $25 an hour, then the sum of all agents working each year plus their business expenses exceeds the sum of all commissions collected each year! The lost time is wasted on unqualified tenants, competing over the few qualified tenants, negative ROI marketing (featuring on NYTimes.com or posting bad photos), etc.
If you believe in the net loss theory, then all the startups that always pitch "broker services a la carte" are doomed to fail. That is, brokers offer some bundle of services and a startup tries to unbundle and charge a fair price per line item. That thinking treats brokers as commodities when we can see clearly that great brokers earn 10x a mediocre broker, suggesting there is probably some skill.
If you want to help, post this patent application to askpatents.com and get some feedback on prior art published there that a patent examiner can find.
This wouldn't be the first time Uber has tried to patent something obvious (http://patents.stackexchange.com/questions/5900/mobile-taxi-...) and I'm sure that they will keep whacking away at bad patents until one slips through. There's very little cost to them to file, and if they are lucky enough to get a bad patent accepted, I'm sure they'll be delighted to use it to block competition.
Some info on what constitutes Prior Art for those interested in participating on Ask Patents
Prior art is any evidence that your invention is already known. Prior art does not need to exist physically or be commercially available. It is enough that someone, somewhere, sometime previously has described or shown or made something that contains a use of technology that is very similar to your invention.
If you asked me two or three years ago I would have strongly agreed with this theory. I used to point out that every line of code was a decision made by a programmer and that programming languages were just better ways to convey all those decisions than human language because they eliminated ambiguity and were much terser.
I changed my mind when I saw how LLMs work. They tend to fill in the ambiguity with good defaults that are somewhere between "how everybody does it" and "how a reasonably bright junior programmer would do it".
So you say "give me a log on screen" and you get something pretty normal with Username and Password and a decent UI and some decent color choices and it works fine.
If you wanted to provide more details, you could tell it to use the background color #f9f9f9, but a part of what surprised my and caused me to change my mind on this matter was that you could also leave that out and you wouldn't get an error; you wouldn't get white text on white background; you would get a decent color that might be #f9f9f9 or might be #a1a1a1 but you saved a lot of time by not thinking about that level of detail and you got a good result.