tomekowal

With qwen3.6-35b-a3b-mtp using lm-studio on RTX 3090, I was getting 120tokens/s. The mtp (multi token prediction) is the key.

I tired coding with Pi and it was much faster than Claude, but for any not-straightforward tasks, it did so so. Either looping itself or not realising easy to spot constraints.

But for exploring codebases and asking questions about big stuff I find it better due to sheer speed.

The article says that domain expertise is more valuable now because agents can code well, but not understand the domain well.

I believe there are domains that are very well encoded. The model very often can know that a shift can't be longer than 11h and if you ask an agent for scheduling software it can surprise the developer by encoding that rule.

Both domain knowledge and coding skills became cheaper.

It might depend on the domain. Highly regulated domains like finance have entire books around how they should work.

However, I agree that verification skills became more important in both areas. A domain expert needs to catch 12h work shifts and experienced programmer needs to catch when the LLM accidentally put a route in a section that doesn't require authentication.

Both require some kind of harness and automatic verifications methods.

Can it run Doom?

Attention! Lawsuit from Blizzard imminent.

There is a hidden hypothesis in this article that AI "does not struggle" with things like undefined behaviour, off by one errors and undefined behaviour.

Yes, it can consistently generate code that works and seems to be on top of it all due to a lot of training data. But wouldn't that use up more tokens and computational resources to produce than e.g. the same program in python?

If using more complex languages requires more resources from LLM, the same principles apply. One-off scripts are better in high level languages. Hot paths executed millions of times a second are better in lower level languages with high optimisation potential.

LLMs might slightly shift the correct choice towards lower languages. E.g. a small one-off script in C is much more viable with LLM's help. But the moment one needs to reuse it, it grows, and needs to be modified, one might regret not using higher level language.

Awesome! Would it be possible to make checkbox number part of the url? This way, I could send someone a link straight to part of canvas, that I worked on :D

Short answer: scheduler.

Long answer: web applications have usually tons of independent request. Each request does its own thing, might never communicate with other requests, touches the DB and returns. You have two choices in such scenarios. You can either maximise throughput or minimise latency. BEAM's scheduler choses the latter which is usually what you want for web. More detailed discussion: https://tkowal.wordpress.com/2015/01/27/the-unintuitive-late...

With:

- per process garbage collection

- one BEAM process per request

- short lived HTTP processes

you might never trigger garbage collection, the whole memory is deallocated at the end of requests.

It basically means, BEAM gives you high level languages like Gleam or Elixir that are fast to write and prototype as Rails or Django, but are almost as performant as handwritten memory managed applications written in low level language.

This is magic sauce in startups: the freedom to go fast, prototype and iterate with scalibility issues popping up waaay later than in Ruby/Python stacks (sometimes never - if your startup is successful without supporting whatsapp's user base :P)

And that's just if you are donig plain old HTTP backend. With new reactive architectures, keeping persistent processes server side and using LiveView instead of JS frameworks can again cut development time.

And then, there is support for AI with LiveBook and NX... It is weird how many hard issues BEAM just makes much easier.

Nice idea and cool looking website! I would re-record the video. It is jittery and it makes the top of the website off-putting. Good luck!

I see standing desk and a monitor arm. My question is: does the arm wobble much when you adjust height? If not: what kind of arm are you using?

My two cents:

1. English is not my first language, and Grammarly helps a lot. Small things like correct punctuation and articles make the text much easier to read for native speakers.

2. I try to make communication "modular". There is tension between over-communicating (giving full context) and under-communicating (leaving out details). The first sentence of each paragraph summarizes the point. If you know that stuff already, you can skip. If you are re-reading, you can quickly get up to speed by skimming first sentences. If you are surprised by the first sentence, read the paragraph.

3. I often use numbers so that my recipient can answer or discuss just one point from my text. That usually starts with "Ad2". You can then "split" the discussion by numbering annotations "Ad2.1". If the conversation gets too long and convoluted, we need to add a summary of what we've written. Both Slack and email have flat conversation structure (Slack threads can go one level deep). That flat structure is usually a good thing for someone following the discussion.

It is very natural, and most people reply in the same way instinctively.

I think that object recognition is hard because humans have much more data than computers. People see with two eyes which can focus on different distances, so our brain has 3D data to learn from. We later learn to recognise the same objects on pictures.

Computers usually start from flat pictures, and that trips the learning process.

I have zero data to back it up. Just my hunch :D

I would change the part: ``` Do you use source control? Do you test code? Do you use bug tracking? Do you use CI/CD? ``` to ``` How do you use source control? How do you test code? How do you perfrom bug tracking? How do you solve CI/CD? ```

For really good companies asking if they test code seems insulting :P

I feel like StarCraft and RTSes in general work really well in this scenario, because they occupy every brain cell available. Concentrating really hard on something non work related totally resets the brain.

To me ideas just come unexpectedly and often because I see someone mistaken https://www.xkcd.com/386/

I had a talk where I showed how Elixir and Elm programming languages complement each other and someone in the audience asked what are we using Elixir for in our company. When I said that for payment systems he looked surprised, because he heard about "let it crash" in Elixir and he thought it is unusable for anything critical. That inspired me to talk about how we use Elixir for handling money.

I also answered questions on Stak Overflow for some time. Of course there are many typos or library quirks that are simply missed, but often you see a person that just entirely misunderstood the concept. This is also a target for talks. There might more people struggling with the same thing (especially if your question gets more views).

Pay attention to what surprises people when you are talking with them. If someone didn't know what you find obvious, there is a good chance more people don't know it. We have some kind of bias where we think that what WE know is common knowledge and automatically EVERYONE ELSE is smarter than us (because they know everything we know and some more that we don't). That is obviously not true :)

If you find a topic that surprised couple of people it means you have and idea worth sharing. It doesn't have to be novel! I often put quotes and references from blog posts that I read about given topic to show that this idea is not new at all! Old ideas are often not widely known or forgotten. They are perfect for conferences, because they might be crystalized over years, so it is easy to research them.

I am working full time with Elixir and Phoenix for more than one year now and worked with Erlang before that. It is great to see how well thought out all the abstractions are (both in the language and in the framework). I saw couple of companies cautiously introducing Phoenix in their stack and then going all in. One of such stories will be presented at Erlang User Conference: http://www.erlang-factory.com/euc2016/ben-marx

Comparing to Ruby: Phoenix promises to be as productive as Rails, but more performant and it keeps the promise if all the libraries you need are already ported to Elixir. Even if not, people consider writing them from scratch.

Comparing to Erlang: Elixir fixes a lot of problems like encoding or inconsistencies in standard library. It introduces many new concepts borrowed from Ruby so it might be a little overwhelming for Erlang developers (Erlang is really small and simple language - the hard part is OTP).

Learning Elixir is like learning to touch type. Initially it slows you down, because you have your habits. You need to learn new abstractions, because old solutions just don't work. After short period you are as productive as before. After a month you can deliver hight quality code quicker which is the ultimate goal of every programmer :) And it magically scales on more machines or at least utilizes all of the cores.

Please, write another textbook.

The internet changed drastically the process of writing books. I saw people making profit from books available online for free. I saw books written chapter by chapter with errors found quickly by first readers. I saw systems that allow commenting parts that are not clear enough with comments how to clarify them.

If you promise to deliver a textbook that teaches skills relevant to engineers, they will fund the time it takes to write the book. I would spare couple of dollars even if you said that it will take 5 years. I believe, there will be even companies that will give you funds upfront. If you reach out for help there will be people who will help you collect example problems from different fields to replace couple of "salt tank problems".

I am not a mathematician, so I don't know how mathematics textbooks are written and how much effort goes into them, so feel free to point out that this idea is stupid.

Have you checked Elm? I know there is a big difference between switching frameworks and entire language, but the benefits are really nice. Elm really enforces unidirectional data flows throughout entire application. For me it's like react on steroids.

Argument "that language was not designed for that!" is valid almost anytime anyone tries to criticize a programming language. Go was designed within Google for Google. Where your system has millions of lines of code and thousands of developers work on them constantly. So they thought about three things: compilation speed, memory management and concurrency. Go compiles fast, so you can iterate quickly. This requires giving up most of the compilation safety checks. They can be done by static analysis tools in parallel. Explicit memory management means, you can sometimes optimize this 0.05% memory on your program. This means a lot, when you run your code on million machines. Concurrency isn't hard in Go, but explicit memory management makes it harder than in Erlang for example (in Erlang, you have "share nothing" policy). Go is also very simple, so one developer won't be surprised by other developer using some obscure feature.

That being said. I wouldn't recommend using Go outside of Google, Facebook or Microsoft. It solves problems, that companies and developers usually don't have. If you need always running and quickly evolving software - there is Erlang and Elixir. If you need guarantees on correctness, use static typing from Haskell. If you can resign from some guarantees to have grater control on memory, there is Rust. If you are writing in browser, there is Elm. If you want to easily transition from OO to functional programming - try Scala. If you need to prototype app for your startup quickly - there is Ruby.

Every popular language has its purpose and its trade-offs. Rust isn't strictly better than Go, but with high probability, it is better than Go for your problem.

The idea is appealing to me, because I always thought, that there should be much more meta data on functions, than module can provide.

I always thought about it like about dimensions.

1. "Logic/test dimension" I can have functions doing actual logic and for tests. Do I put it in one module (to make it easy to change both if I need to) or in separate module (to make business logic more easy to follow).

2. "Data structure dimension" I can have functions operating on different data structures like lists and sets.

3. "Operating dimension" I can have functions operating on "Enumerables". Do I put map in the Lists module or Enumberable? I need to know, where someone else put it when debugging. Database operating on meta data would solve that problem.

4. There can be metadata for time/space complexity, so I can easily make tradeoffs between functions that do the same thing in different ways.

5. "prod/stg/dev dimension" is another one. Maybe I want to use completely different logging mechanism for stg and prod, because I pay per logline...

6. "Quality dimension" could show, what is the code coverage for the function or if it follows naming conventions/practices.

7. "Popularity dimension" could show, how often is given function referenced, which would show most important functions and where to focus on optimizing.

Some of this problems are solved in different ways. IDEs can jump from function usage to its implementation. If you follow conventions, you can jump to a test code for given function. In Elixir, you can jump to protocol implementation. I can use inversion of control for switching implementations between environments. Those problems would have single solution, if there was a central database for functions.

There are many, many more dimensions and even relations between them.

Good guess :) But I am from Cracow, so I don't know about Erlang positions in Warsaw. I know couple of positions in Cracow, though.

There is a site dedicated to Erlang, which also has jobs section with varying Erlang skills required https://erlangcentral.org/jobs/