I'm not sure quantum computing is the solution, but it strikes me that a completely new compute paradigm like quantum computing is probably what is necessary - which is orders of magnitude more efficient and powerful than today's binary compute.
2,593 karma · joined October 15, 2012
E-mail: sixdimensional ATAT [dimensionsix DOT com] minus the ATAT and brackets.
Whether it's a mirage or not, the ability to produce a symbolically logical result that has valuable meaning seems real enough to me.
Especially since most meaning is assigned by humans onto the world... so too can we choose to assign meaning (or not) to the output of a chain of symbolic logic processing?
Edit: maybe it is not so much that an LLM calculates/evaluates the result of symbolic logic as it is that it "follows" the pattern of logic encoded into the model.
Personal profit maximization only works to a point - for example, if you get too old, sick or the system rejects you early and curtails or limits your ability to make money.
I don't disagree that money gives you options, but, far too many people wait until they have enough money to give back.
If you give back while you are working (e.g. balancing working for profit vs working for nonprofit, altruistic reasons, etc.) - that's awesome. The challenge there is maximizing the good you can do if you're giving too much time and energy to your profit maximization.
At some point, someone has do physically do the needed good work.
For myself, the calculus has shifted. I personally decided I cannot wait until I have enough money, or I am maximizing my profit, to go out and help people.
I also cannot wait until I am physically or mentally unable to help beyond financial contributions. Also, I cannot afford to work in the current system that drains everything from you and leaves you no energy or time left, only money (if that).
Regarding the inherent maximum scaling limits of one person- I would challenge your thinking.
Power laws of networks may demonstrate that helping a small number of the right people might be enough to unleash the butterfly effect or play into ongoing changes.
Also, the physical limits of humanity on one person apply to a billionaire as much as a person with little money. I'm not saying a billionaire, millionaire, or person with significant finances isn't more mobile/capable, but it's not a given.
I am for reasonable profit and balance. There is nothing inherently wrong with maximizing profit if someone chooses.
But if we all spend our time on maximizing profit, there still, for the time being and probably well into the future, still needs to be boots on the ground doing work that is not for profit.
In this case, it's so easy for some to say everything else is bad if it is not AI, or you have to include AI "because it's the future".
I just wanted to clarify that I am very pragmatic in my approach to new tech and AI.
I used to work on enterprise ERP, MRP, sales and support systems (Oracle, Salesforce, ServiceNow, and more)... not always by choice.
At one point a project came up to rebuild our core customer experience portal across our business. I got to build with the rule based chatbots to implement an assistant in that web app.
Not easy, but it worked well enough, especially for simple scenarios. For example, imagine a field support engineer being able to pull up the exact page in a big technical document for some obscure part by just asking for what they need, in seconds.
Or, being able to reorder some quantity of part by just asking for it, or checking the quantity of same.
These are time savers, especially if you have a voice to assistant interface too. So you can just type something, or ask for what you need without typing.
Tablets were common for manufacturing, inventory or service staff. Being able to pull up our interface and just say what they needed and get prompted for simple things - there were TONs of pragmatic small wins there.
Current LLM just make that easier than the old rigid rule based way we had to code those assistants (at the price of going wrong sometimes).
I care about efficiency, pleasant user experience, and pragmatics.. not AI for the sake of AI.
All that to say, if a drop down box works better for some use case, instead of AI - or even a rule based chatbot - hell yeah! Save on them tokens.
Genuine question though - have you implemented an AI assistant/chat interface recently using LLMs on top of a UI?
I agree it can be a rabbit hole, but I just got through doing it on an app and there were definitely some things it really made way simpler and some complex scenarios that I'm not sure could have been done any more simply.
I agree with the right abstraction and it's tough to find the balance- in our data pipeline app, what we did is make key core functionality of the app exposed so the assistant can use it, and implemented a handful of basic agents out of the box, including one default one that could shell out work to others. We also made it easy as an extension point for users to add a new agent that used the core functionality/tools, just by defining the agent in a markdown file.
We found starting small for critical use cases that saved the most time, but thinking about building blocks, was useful.
Because the responses of the AI assistant come back and are processed on the UI, we found we could give the LLM our UI docs as well as knowledge about UI element IDs, etc so it could respond with input commands that would drive the UI.
This way, we could do something like, provide the LLM with the input/prompt including the context of like - what page/view is the user on, what is their intent, what tools are available in general, what sub agents are available for specialized tasks, etc.
Please don't let my suggestions sway you away from core progress in your app (take with a grain of salt). But it's great you're already experimenting- keep your eyes open if you see a great use case where it accelerates workflow.
Another HNer mentioned people not reading docs- that's a low hanging fruit use case we had too - "how do I use this view?", "what does this field mean?", or retrieving information from other parts of the app without having to navigate away, etc. It can save having to find answers in a doc or navigate elsewhere.
Edit: perhaps a useful exercise - imagine a workflow of "talking to the app to achieve a task" as a way to explore.
"Hey ERP, open the part entry screen for part 12345"
"Hey ERP, can you update the description for part 12345 to correct the spelling error?"
"Hey ERP, how many of widget XYZ are in stock? If there are enough in stock, can you transfer quantity 10 from warehouse A to B?"
"Hey ERP, how do I cancel a sales order?"
"Hey ERP, how does this screen work?"
I think if you break these down, you'll find common abstractions that map to features, API endpoints, user interface sequences and interactions, triggering workflows, looking things up in docs, etc.
I used to work in green screen text based UIs from the 80s (TUI).
Power users didn't need search or anything else - they memorized the keystrokes to navigate the text UI and could just type key combinations to blaze through the UI faster than it could render on the screen.
I've never really seen anyone able to replicate that UI in a browser based or GUI desktop app to be honest.
Power users are a different use case, although the end goal is to remove the need for clicks.
I don't believe chatbots/AI assistants are a panacea, definitely encourage the architects of this new ERP platform to weigh the pros and cons.
That said, two jobs back I worked for a major manufacturing company that used the old GUI destop based Oracle EBS ERP. To automate repetitive workflows they were trying to implement UIPath (RPA automation - it drives the UI for the user) on top of the GUI.
This is what lead me to believe that if the ERP application's functionality is discoverable by an AI assistant, it can be used to automate or navigate on behalf of the user, or as part of complex workflows.
That can be done later after the basics are addressed - my only advice would be to just consider it sooner, even if you don't build it first.
It's a little easier to think of how one might simplify the workflows and design for automation into the core of the product, via the UI, APIs, etc earlier than later.
But in general - focus on the user's needs first and different roles/personas - just don't completely ignore new types of automation workflow opportunities (i.e. AI assistants/chatbots).
My opinion only.
An example: - user intent is to update an attribute for a component part number A21445
- user can click a chat bubble icon in lower right and chat to the assistant
- user describes their intent - "help me update the description for part number A21445
- system replies by informing the user it will open the right screen, opening a part/component editing UI, with the right part loaded, with the cursor positioned in the description field, and the assistant stays open for further assistance; or;
- system replies that it found the part and can update the description, shows the current description for the user, asks "what description do you want?"
- user enters updated description
- system confirms the change is correct
- user confirms the change is correct
- part/component description is updated without even opening the UI
FWIW, it's great that you have cmd-K and also I've seen those kind of search boxes get more smarts like being able to type "part:A21445" to go directly to a specific UI.
I just suggested the above as we learned some interesting user experiences became possible when our AI assistant had the ability to control our UI directly on behalf of a specific user.
An example in the app I worked in (a web based data pipeline tool):
- "Hey assistant, can you help me add some SQL transformation logic to dataflow ABC, to process the customer data?"
- system uses metadata and knowledge of the UI to open the right dataflow, select the right type of UI to open to enable the user to add a SQL query in the right place, maybe even autogenerate the initial SQL query - this all from the main home page of the app, from a side panel chat assistant.
- net result feels like talking to the assistant to operate the app, almost no clicks required.
I hope that makes sense.
In a previous job, we built our AI assistant so that it could operate our UI in the front-end and it was very powerful.
I thought the TAMDAR tech reference might be if interest to those following and reading comments here.
I'm not associated with them anymore and I'm not sure how much of their model still exists after the assets were sold to flyht, but I hope it does because we need good weather models!
Fair enough being vigilant, but not an ad.
The weather model from PWS was incredible, using TAMDAR sensors mounted on commercial aircraft, which recorded data at multiple altitudes getting a great sample of conditions from many layers of the atmosphere as aircraft ascend and descend.
IIRC, during hurricane season some years ago, the PWS model outperformed hurricane path predictions from many other organizations in terms of accuracy, among other things.
I love this share too, and I suspect this weather data could be very useful!
[2] https://flyht.com/investors/news-and-media/view/flyht-acquir...
Model = what is the type of the thing
Serial Number = was supposed to be what order the things were made in (e.g. the number of the serial order), but this is often obfuscated or often repeats [1].
In cars, make would be like Ford. Model would be like Focus, serial number would be VIN (vehicle identification number - in cars, those are generally unique!).
Ford Focus + VIN, basically.
There is a theoretical concept of a unique identifier for everything... including people from ISO under ISO 8000.. combining a natural location identifier (eNLI)[2] and an ISO8601 timestamp - to represent "where and when a thing is considered to be born" - a point in time and space the thing is considered to come into existence.
I think the idea is called "natural person identifier" for humans.
This ID has to be assigned but I think you can see the idea at least.
I suppose this doesn't include make/manufacturer but realistically that isn't needed for uniqueness in this scheme, only as descriptive metadata for things that have one.
[1] This is related to the fact that if serial numbers were truly serial, one could estimate the rate and quantity of production which is considered sensitive information by most manufacturers. This relates to "the German tank problem" - during WWII the allies were able to accurately estimate the production of German tanks by analyzing the serial numbers off captured tanks.
[2] https://eccma.org/enli-eccma-natural-location-identifier/
Aircraft do not have a singular unique identifier that is time invariant.
While it is true that aircraft have serial numbers issued to their airframe, by itself, aircraft serial numbers are not unique.
The only unique identifier for an aircraft across its lifecycle from production to end of life is a combination of the manufacturer, make and serial number.
I know this because I am on (for better or worse) the patent that involves defining that as a unique identifier for aircraft.
The combination of ICAO aircraft type designator + serial number approximately is the most permanent identifier for an airframe - and even then - if an airframe is modified significantly enough that it no longer is the previous type - even then this identifier can change.
Personally, it boggled my mind that something as big as an aircraft did not have a simple time invariant unique identifier.
P.S. For those who might ask - aircraft registration numbers are like license plates, so they change - tail numbers can be ambiguous and misinterpreted depending on what is painted on the aircraft where, and ICAO 24-bit aircraft addresses are tied to ADS-B transponder boxes, which technically can be moved and reprogrammed between aircraft also.
Regardless of the complex history of CentOS, RHEL, etc it seems like the original thrust of CentOS lives on rebranded as RockyLinux for example.. and CentOS stream serves Redhat's needs/purposes.
I think forking still is a valid method to resolving challenges for NATS here.
Couldn't Synadia just fork what they want to and rebrand for a commercial new product, and go forward from there?
If they wanted to backport or keep contributing to the open source project they could, or leave some parts open source going forward, while forking only the server for example, to do that.
Kind of like how RHEL used to still provide contributions to CentOS for a long time (although I think that ended at some point too).
That said, I think you raise a bigger issue - I'd like to see MORE things like Framework, Fairphone or Slate - user serviceable, customizable - maybe low initial cost.
To me, this feels futuristic, exciting, optimistic and positive.. we need more like this, so how can we make these kinds of businesses more likely to succeed, resilient, etc?
If I may so bold as to refer to you as "my friend" (having never met you)...
My friend, I think I understand what you mean. I am about the same age too.
I would like to propose an idea to you - and it is something I have been exploring very deeply myself lately.. maybe the thing we need to start spending our time on is exactly this meta problem now. The meta problem is something like (not perfectly stated): we as humans have to decide what we value such that we can continue to give our existence purpose in the future.
I don't think AI is going to be the be-all-end-all, but it is clearly a major shift that will keep transforming work and life.
I can't point yet at a specific job, or task - but I am spending real time on this meta problem and starting to come up with some ideas. Maybe we can be part of what gets the world, and humans, ready for the future - applying our problem solving skills to that next problem?
I mean all of the above in 100% seriousness and I am willing to chat sometime if interested to compare notes.
On the other side, for many of my thoughts/ideas/creativity, I find it is often a question of, do I die alone with it in my head or put it out there, maybe for someone to find, use or be inspired by? If it's a question of one or the other, I think perhaps I'd rather let it go free so the value isn't lost (assuming, that what I have to write/say/share is of some value).
I have seen that mechanism be exploited.. sometimes you put something out there, someone uses it, and there is zero attribution/citation. For myself, I prefer to try (most of the time) to treat non-fictional writing in the traditional sense of an academic paper and include citations whenever they are useful and I can - even for non-academic purposes - for the purposes of giving credit to others. It's nice to share credit and show how things connect, IMHO.
FWIW, I like some of the inspiration behind Creative Commons, but even old school citations (MLA/ALA or heck, even just this kind of inline citation style [1] that is common on HN and other sites is better than zero).
There are citation generators online also [2] - for formal purposes/writing/papers you must get these formats right, but for informal/casual use, I think simple citation is better than no citation.
[1] simple citation style, or even just paste the URL - at least you're giving credit.
[2] example, https://zbib.org/
I love it personally and it looks pretty good so far. Also, amazing that the team started it as an open source project under a 501c3 nonprofit as well.
Having a more "spreadsheet" (or I would say, MS Access-like) UI is quite cool for certain use cases (e.g. low/no-code but backed by the full power of regular old Postgres). Can allow pretty agile development, although - it can get out of control if not managed with care... but nice to see the access controls/permissions there to help a bit.
All interesting choices, looks cool!
Plain dict maintains insertion order but equality checks only check that the key/value pairs are the same. [2] [3]
[1] https://docs.python.org/3/library/collections.html#:~:text=e...
[2] https://docs.python.org/3/library/stdtypes.html#:~:text=dict...
[3] https://docs.python.org/3/library/stdtypes.html#:~:text=dict...
Testing SQL is not impossible – SQL unit testing is a thing – identify a unit of SQL, such as a query, function, or stored procedure - mock the necessary inputs and any state that is modified and check the result of the unit just as you would in any unit testing framework (e.g. arrange, act, assert). Perhaps it’s a little difficult, or different to wrap our heads around (and many do not take the time to see how this can work) but it’s not impossible.
Also, as others have already pointed out, depending on the implementation of the SQL engine itself, different engines can have very different behaviors, some of which make composable SQL possible already today (e.g. table valued functions, CTEs that are inlined, stored procedures, etc).
And for what it’s worth, if you look at a lot of the data processing engines we use today (such as Apache Spark), they really solve the problem of being able to compose and modularize code and SQL together, through data frames or things like language integrated query, integrations of languages that compile down to code that can run and be orchestrated on common execution engines, and so forth.
I'm not affiliated with them, I just think it's a good idea and they are making some real traction.
Fairly simple and somewhat fun.. Python has PEG parsing built in, but also the pyparsing or parsimonious modules too.
I have built EDI X12 parsers and toy languages with this.
[1] https://en.wikipedia.org/wiki/Parsing_expression_grammar