gawi

If you are able to isolate the text portion corresponding to the company name, you can compute the similarity (based on the character edit distance - Levenshtein) against every item of a predefined list of companies (and their aliases) and pick the best match.

LangChain is a perpetual hackathon.

Not sure I like the "I know better" attitude of the LLM in this case. What other function response the LLM is likely to discard?

It's only been added to the OpenAI interface. Function calling is really useful when used with agents. To include that to agents would require some redesign as the tool instructions should be removed from the prompt templates in favor of function definitions in the API request. The response parsing code would also be affected.

I just hope they won't come up with yet another agent type.

When I first encountered the Haskell Parsec library, the beauty of parser combinators hit me and I felt I'd never have to write a regular expression again.

This hasn't been the case because I had to work in other languages where usage of regexes was more idiomatic/commonly understood. Parser combinators are great but most of the time, the problem can easily be solved using a regex and we can't really justify adding yet another library in the dependencies for the rare case it would be better suited.

In addition to all the benefits they can provide in terms or readability, re-usability and abstraction, parser combinators can even compete with regexes in terms of performance. https://pl-rants.net/posts/regexes-and-combinators/

I really like the cover where you can find illustrations of anti-patterns such as stovepipes, gas factories, reinventing the wheel, etc.

Can you names the others?

I really like your explanation, which I find easier to understand. I do appreciate your "real-life" AST example, making clear that your are making a better design through the typing system facilities.

Understanding how GADT works only comes next to understanding how leveraging the typing system during design can be beneficial. The motivation to go through this tutorial stems from the desire to let the typing system strengthen the programs and API. I'm coming from the Java world and I've spent some time learning Haskell for my own culture. At the time, I was trying to use Java generics to encode some restrictions in my design. It was interesting but alas a bit limited by the Java generics implementation and the results were most of the time hard to use or understand.

I'd like to see more articles on how GADT (or any other mechanism) can improve a concret design, with real-life examples. Starting with a native design leveraging only a few tricks from the typing system up to a final version where constraints are properly encoded.

One has to ponder if starting teching that will result in the next TikTok bleach+vinegar inhalation challenge.

I agree. I gave up and went straight to HN comments.

Nice plug in the middle of middle of the article, exactly at the right spot:

> By the way, I write an article like this every month or so, covering lessons learned from growing B2B software startups. Get an email update when the next one is published

This is the closest I got to subscribing to a newsletter.

Further in the text:

> A Neural Module’s inputs/outputs have a Neural Type, that describes the semantics, the axis order, and the dimensions of the input/output tensor. This typing allows Neural Modules to be safely chained together to build applications, as in the ASR example below.

Around the same period, in the telephony world, IVR (interactive voice response) systems entered the web universe with the VoiceXML W3C recommendation. It allowed IVR developers to write server-side web applications as ordinary web applications, the HTML being substituted by VoiceXML.

Given the very linear nature of an IVR dialog, it became clear that a continuation-based approach would greatly simplify development, as mentioned in the article.

The Nu Echo "Rivr" Java framework was created around this idea. However, since there is no native continuation in Java (yet!), it was approximated through thread-based coroutines.

The payoff for the developers is huge. It allows the developer to directly "map" a dialog specification to Java code. Abstractions can easily be introduced without having to create an explicit model for the state (the state is just the set of the variables and objects referred by the thread). This approach is much more flexible than state-machine based paradigms.

Even though all architectural issues mentioned here are valid (namely the lack of session-based fault-tolerance), it turned out to be somewhat manageable in real-life situations because in this type of system, there is a limited number of calls handled simultaneously and their average duration is typically a few minutes.

Rivr is still used today and we are currently defining mechanisms with HAProxy to implement no-downtime scenarios in Kubernetes.

This is very interesting. I have no doubts that not having to deal with fault tolerance at the application level compensates for the efforts to put in place this architecture. And yes, in my opinion, "application-level consensus" is the perfect term to designate this architecture.

Better yet: 4 lines of code + a few lines of comments.

Donald Trump's failed attempt to shut down the Internet.

I know this is highly pedantic but CURRENT_SPEED is not a constant and therefore shouldn't be all caps.

It's wrong wrong wrong on so many levels. It's more unthinkable than impossible.

Not even using libasteroid...

On the net, everyday is April 1st.

Agreed that Haskell might not be to perfect fit for most of the enterprise projects out there, BUT nevertheless it is worth learning and mastering. The perceived difficulty comes from decades of teaching of imperative programming. I'm myself the product of C/C++/Java and it's amazing how I've manage to deal with so many peculiarities of theses languages. After having learned Haskell, I realize that it's much more coherent than the vast majority of other programming languages (including the functional languages). I'm learning Scala today and frankly, Haskell is much simpler. It is just amazing what you can achieve with good abstractions (parallelism, performance, modularity).

You might be tempted to use it yet but I'd suggest you keep on eye on this language. The potential is great and Haskell is evolving quite fast.

No offense, it's just funny ;) Provocative titles are good, they create a debate. It's true that I was playing the devil's advocate.

Long title would be "Hey you Haskell guys, everybody is thrilled about node.js, why don't you explain how to achieve high scalability in Haskell without sacrificing the program structure. C'mon guys, I know you can!"

If Haskell is leading the way, they should have some response about node.js, right? Whether or not this can be mainstream and deployed everywhere is another question. I totally respect Haskeller position regarding the experimental/research status of the language.

This is funny. I'm the person having submitted the question on StackOverflow. KirinDave just assumed I was a Node.js hacker (which is absolutely not true!). I really wanted to understand how Haskell is planning to attack the >10k-100k connections problem. The question was just an excuse to talk about the Haskell-way.

Personally, I think Node.js offers a regressive programming model and I'm concerned about too many peoples diving into it. Ryan Dahl is a very smart guy, doing a nice job and is greatly responsible for the success of Node.js. The rumors goes he would have been tempted to do something with Haskell first but he stepped back as he was not familiar enough with GHC. Actually, that not a rumor, that's what he said: http://bostinnovation.com/2011/01/31/node-js-interview-4-que...

The problem with Haskell is that Haskellers are very smart peoples (...smart peoples again!). They became very comfortable with some hard to grasp concepts for programmers having a more conventional pedigree and might underestimate the education effort required in order to attract more programmers. Most of them are not necessarily focused at creating a more accessible language but rather explore new FP concepts (which is great, BTW). Things need to change in university classes first.

So you have potentially hard to maintain callback code on the node.js side and monad/lazyness/FR to master on the Haskell side. Nevertheless, from a skill-improvement point of view, I think the Haskell option is a much better investment.

Back to my Scala book now... :)

Never trust a programmer who says he knows C++... Never trust someone who says he knows... Never trust a programmer... Never trust C++ ... Never C++...

At university, they taught me C++. I suffered a lot. So the minute I graduated, I stopped doing it. This was a valuable lesson after all.

If someone pretends to understand C++, just look at his code and say "Ok, so what happens if you add 'volatile' just here."