> Without patents, people fall back to copying each other, because it is much easier to copy than to innovate.
This is probably the only argument I've seen in favour of software patents in which I see any merit!
1,857 karma · joined May 8, 2015
rver017@aucklanduni.ac.nz
This is probably the only argument I've seen in favour of software patents in which I see any merit!
There are hundreds of trillions of synapses in the brain, and much of what they do (IANANS) could reasonably be described as pattern matching: mostly sitting idle waiting for patterns. (Since dendritic trees perform a lot of computation (for example, combining inputs at each branch), if you want to count the number of pattern matchers in the branch you can't just count neurons. A neuron can recognise more than one pattern.)
So yes, thanks to its insanely parallel architecture, the brain is also an insanely brute force pattern matcher, constantly matching against who knows how many trillions of previously seen patterns. (BTW IMHO this is why LLMs work so well)
(I do recognise the gap in my argument: are all those neurons actually receiving inputs to match against, or are they 'gated'? But we're really just arguing about semantics of applying "brute force", a CS term, to a neural architecture, where it has no definition.)
Very little data about expenses, but it looks like they may be growing a little slower (3-4x a year) than revenue. Which makes sense because inference and training get more efficient over time.
This is why so many people (especially those that think they understand LLM limitations) massively underestimate the future progress of LLMs: people everywhere can see architectural problems and are working on fixing them. These aren't fundamental limitations of large DNN language models in general. Architecture can be adjusted. Turns out you can even put recurrence back in (SSMs) without worse scalability.
Not much but it likely has something to do with it, so experiments on access consciousness can still be useful to that question. You seem to be making an implication about their motivations which is clearly wrong, when they've been saying for years that they do care about (phenomenal) consciousness, as bobbylarrybobb said.
There are loads of scripting languages but very few of them have an embedding API as powerful as Lua or Squirrel's. (My benchmarks: what's the overhead of a userdata pointer? Is there a proper debug API? Can you suspend a co-routine from inside a called C function? Very few languages even have coroutines.) Last I looked at it years ago, Wren was one of the best. Of course, the most featureful embedding API of all belongs to LuaJIT.
An overview for Rule 110: https://cs.stackexchange.com/a/4780
Irrelevant aside: I've been using emacs 20 years but I very recently gave up and mapped ctrl-V to paste because I still made the mistake of hitting that too often. (I don't hit ctrl-C accidentally, because to select text I've already switched to emacs for at least a few seconds.)
When I first heard about Julia I understood it to be a faster alternative to Python. As I started to learn it I realised that's really not what it's about, it's trying hard to compete simultaneously with Matlab and R and Fortran and C++ (and the template metaprogramming language hiding in C++) and APL and Lisp and maybe OCaml just as much as Python (but not Rust or Java or Agda), and I can't even speak to the other languages mentioned.
I've been diving in to the ECA protocol a bit to debug some emacs issues, and from glancing at the ACP (Agent Client Protocol) documentation, it seems that the ECA and ACP protocols are incredibly similar, and both very well documented. An accident of reinvention.
This library might have saved me a lot of time recently, as I don't have a working scanner and was forced to photograph and clean up a lot of pages of documents. I used gimp, which required a lot of experimentation. It's only got a couple adaptive tools that can do the job with uneven lighting, but they sometimes require some pre or post processing for good results.
I haven't tried Jules in a couple weeks, but the UI/UX had a lot of issues such as not being given any progress updates for very long times. The worst thing was not being able to see what it was doing and correct it: you only see the state of files (without a usable diff viewer, WTF) at the last point that the agent decided to show you anything (the last time it completed a todo list item I think, and I couldn't get it to update the state when asked, though it will send a PR if you ask), and gemini-2.5-pro can often try really stupid things as it tries to debug. I've also been impressed at its debugging abilities a number of times.
Still, I found Jules far more usable than Gemini CLI (free tier), where Gemini just constantly stops for no reason and needs to be told to continue, and I exhausted the usage limit in minutes.
Aside from the unlimited free tier, probably the best part of Jules are its automated code reviews. Once, I was writing up some extensive comments on its code and then unexpectedly a code review was dropped in the conversation which gave exactly the same feedback I was writing. Unfortunately if it never reaches the point of submitting for review, it doesn't get an automated review. It does often ask for feedback before it's done, which is nice. So probably I needed to prompt better.
-create a separate linux user, put it in an 'appshare' group, set its umask to 002 (default rwxrwxr.x)
-optional: setup some symlinks from its home dir to mine such as various ~/.config/... so it can use my installed packages and opencode config, etc. I have the option to give it limited write access with chgrp to appshare and chmod g+w (e.g. julia's cache)
-optional: setup firewall rules
-if it only needs read-only access to my git history it can work in a git worktree. I can then make git commits with my user account from the worktree. Or I can chgrp/chown my main working copy. Otherwise it needs a separate checkout
And I've had a brief try myself. The interface, /help and even copilot --help show nothing about which model you're using or how to switch between them. There's no /model command. Thankfully Simon describes that. The fact that you can't switch to a model that Copilot normally offers unlimited usage of, such as GPT-4.1, is very disappointing. (I tried it and it didn't work, doesn't even print an error for invalid model ID.)
It seems that they wrote this from scratch as it's missing the features you'll find in any other CLI tool such as opencode, crush, Claude Code, etc. It's a little bit bare. The interface is somewhat different and better or worse in some ways. It's good that it uses normal terminal scroll-back instead of hiding it, but you can still expand/collapse tool outputs. Really wish I could expand a single one though. Viewing outputs of running tools live glitches up the terminal UI, at least in xfce4-terminal.
Instead of showing you how much of the context window remains like some other CLIs, it shows how many requests you have remaining this month.
Also still active after 29 years in development :) and even still looks much the same as its MS-DOS days.... so decades of work left to do. Recently ported to modern consoles (for Fighto Fantasy & Axe Cop RPG)!
I hope it didn't take too long for you to discover the wonder of GOSUB -- simulating it with GOTO and IF is a pain! GOSUB is just a single x86 'call' instruction and RETURN a single 'ret' instruction. So simple; a taste of assembly programming without stack frames. I even reimplemented GOSUB/RETURN as macros with assembly in FreeBASIC that way (you could just push to the stack). And putting all your code in a single scope, no locals/globals/arguments, makes coding more "fun".