Windsurf goes looking into the codebase and learning context before attacking the problem in my experience. Often Cursor tries it's best to just guess the solution without context and only really resorts to going deeper when you tell it they fails.
I find if I tell Windsurf to look at something it will, Cursor I sometimes lay everything out for it and it just doesn't even read it.
Ultimately though once you run out of requests on Windsurf it's very weak without Claude though, and the top up requests are burnt through too quickly.
I trialled Cursor for a month and then Windsurf. Cursor read entire code files in while Windsurf would read the first 100 lines (or was it 50?), then the next 100, and often stop before it got to the part of the file with the method in which was needed.
No, a "view that humanity ought to be replaced" is Sutton's, not an EA view. I'm not quite sure how you read that otherwise, except that you seem very angry. I sure hope our alternatives are better than human extinction or total control by elites...
Sure the ideas go away away back - but most people had given up on neural nets after the initial excitement, and sure others were also working on it - however the difference for me is he used it to solve real world interesting problems - and by showing what was possible - that ignited the resurgence.
Now you could argue that the people in the 60's and 70's didn't have the compute available to make non-toy networks, and it was only applying the same techniques on bigger datasets with more compute that was the real difference.
Sure - but that happens all the time in science - every innovation is building on the shoulders of others and the assignment of the Nobel prize is as a result often rather arbitrary.
Also don't underestimate the value of reducing to practice - the difference between coming up with an idea and actually making it work in practice.
TS is actually has better typing than Python (mypy). And the whole React (Vue, etc) infrastructure around it. Without these two things I wouldn't even bother writing frontend code.
Idk they're just different tradeoffs to me. Types are real and enforceable at runtime in Python (e.g, pydantic). Types in TS/JS are a fake veneer that add a build step. Is that categorically better? I don't love Python typing syntax.
I want my types to be verified before runtime, what should I do with type error at runtime? Yes it will leave me a better error message in logs, but build-time type check will prevent me even rolling this code out.
> I want my types to be verified before runtime, what should I do with type error at runtime?
It is weird to me you cannot think of uses for types and handling their errors at runtime. Look at projects like FastAPI (which uses pydantic) for an an example where having types at runtime has been handy.
Also, if types are enforced at runtime logging is better, debugging is better, and you have more options for data validation and doing dynamic or metaprogramming likely more easily because you can evaluate these things at runtime. By types being built in, the language gives you a richer set of tools to work with and more options when and how to enforce types.
> Look at projects like FastAPI (which uses pydantic) for an an example where having types at runtime has been handy.
What is it, they have nice error messages? I don't expect them to fix code at runtime when type error happens.
> Also, if types are enforced at runtime logging is better, debugging is better
These can't even happen with type checking in the first place.
> you have more options for data validation
In my experience serializing/deserializing data is pretty much the only place where its useful, and it doesn't have to be built-in on a language level, Pydantic is doing it well enough.
> doing dynamic or metaprogramming likely more easily
This is where you lose me, I have never seen it being useful in reasonable large projects in popular languages. Dynamic or metaprogramming only works in a very specific category of languages (lisp-likes), doing it in any other language will become a problem sooner or later.
> more options when and how to enforce types
Again its only on serialization level, apart from that type checking will cover everything before runtime, it's weird to me how you can think that encountering problem later has any advantage of doing it earlier.
> What is it, they have nice error messages? I don't expect them to fix code at runtime when type error happens.
FastAPI validate both data (serialization) and schemas (used to create APIs and specs). Pydantic can also help with safe casting, not sure if FastApi uses that or not, but it is available
> These can't even happen with type checking in the first place.
I mean when you're debugging any problem or learning an API. It is nice to have rich types built in, especially while in a REPL, where you can inspect types.
> In my experience serializing/deserializing data is pretty much the only place where its useful, and it doesn't have to be built-in on a language level, Pydantic is doing it well enough.
Pydantic relies on Python having types built into the language and available at runtime.
I thought I read somewhere that the Chrome team tried typed JS, found out that there was a performance hit, and they ended the experiment? Is this a continuation of that or a new effort? Sounds interesting.
Do you actually see and modify code in your browser today? I mean for like 5 years all you see in the browser is minified and obfuscated to the point its almost impossible to make any practical sense out of it.
