421–430 of 448 posts
Earlier quoted context omitted.
Oh, you're onto something. May I slap a sticker on it and call it "agile"?
How about "extreme programming"?
Earlier quoted context omitted.
Electricity famously took perhaps twenty years for people to slowly figure out how to re-organise factories around it.. Hence the delayed impact on productivity figures. To elaborate: in the bad old days of you had one big engine, eg a steam engine, that was driving shafts and belts all around the factory. There was a lot of friction, and this was dangerous. So you had to carefully design your factory around these co…
Adoption takes time, for sure, especially when dealing with fixed assets like a factory. The difference I'm poking at is that electricity had a clear value proposition and improved over time. I see people looking for the value proposition in GenAI/LLMs, which brings me to the original question. If GenAI now was like early electricity, we would know what we wanted to use it for, even if we weren't there yet. That isn'…
I was talking about the need to re-imagine and re-organise how factories work, not about the physical factories themselves. So it's more like a 'software' problem.
> Does anyone here see GenAI teams being spun up for "management" by a human? Or do we see fancy Google search / code completion?
How would the two cases look different? If you have a human worker that uses GenAI to help her complete tasks (via something like fancy auto-completion of text, code etc) that previously took a whole human team, that's exactly how you would 'spin up a team of GenAI for management by a human' would look like, wouldn't it?
It's just our framing that's different, and perhaps who that human is: you take someone who's familiar with the actual work and give her the tools to be faster, instead of taking someone who's more familiar with the meta-level work of managing humans.
I suspect that's because managing humans is a rather specialised skill in the grand scheme of things, and one that doesn't help much with telling GenAI what to do. (And, human managers are more expensive per hour than individual contributors.)
---
In any case, I agree that GenAI at the moment is still too immature to be trusted with much on its own. I hope more globally optimising AI like AlphaGo etc comes back in style, instead of essentially 'greedy' contemporary GenAI that just produces one token after another.
Earlier quoted context omitted.
> Vendor lock-in from a single vendor? Wildly expensive capex and opex? Impossibility for people to know any of the tech involved without you sending them on a course to learn about it or them already having experience with it? Is this a trick question? The answer is 'yes' to all three.
For mainframes, it is. For AWS, it isn't. Outside of a few narrow exceptions, there is no vendor lock-in into a single vendor. (A container that can run into Lambda can run into Google Cloud Run just fine). There is no capex with AWS. There's a free tier and it's freely accessible to anyone. Anyone , and I mean anyone , can start learning it if they want to. Good luck getting access to a mainframe to play around to s…
The grandpa developer delivered a function, not a .zip file. Nowadays the developer needs to deliver a .zip file -- because the developer is responsible for wrapping the function in something that executes the function -- often SpringBoot in corporate environment.
He could use AWS Lambdas, but that locks them in. Also, you need to worry about restart times, and price/performance is high, because there are many layers of virtualization.
But the biggest loss is that in "best-of-breed architecture" (bunch microservices running in Kubernetes) the developers have in practice no way of guaranteeing data integrity. Systems are in perpetually inconsistent state (called "eventual consistency") and we just pretend the problem does not exist.
The grandpa developer could develop functions that would call other functions, and all would be executed within a transaction. It would be within his means to maintain data integrity.
For the individual developer, the situation is much better. I can get my Django application to be hosted on fly.io in no time and it is quite cheap. I think the cost of running services is temporarily subsidized by influx of VC money, but that will eventually change.
Earlier quoted context omitted.
Apple is a company, not an operating system. The parent is almost certainly aware macOS is BSD-based and is suggesting Apple also uses Linux in e.g. cloud deployments. They are of course correct.
> The parent is almost certainly aware macOS is BSD-based Doubtful. Surely they would know macOS is XNU-based?
I work for Red Hat in the kernel maintenance team.
Edit: i just realised you were doubting the correctness that it was BSD, not that I knew.
Earlier quoted context omitted.
> IMHO, the best way to do it is to be sitting with the expert, and observe exactly what they do. Or you give them a prototype of the program, and see what they complain about?
My experience is that invariably results in "development by veto". Each prototype they say that's not what I want, give me something else (that I'll fail to describe just like the last time) and I'll tell you that is wrong too after you've worked on it for a few weeks. Occasionally, you'll randomly get something they accept - but only for a few weeks until they come across some missing capability for some other thing…
Yes, I wasn't entirely serious.
Though you can get pretty far by doing some roleplay, where you pretend to be the computer/system (perhaps put up paper screen to make it easier to roleplay, and pass messages written on paper) and have the expert interact.
Earlier quoted context omitted.
It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all. The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X. But that…
My experience with "business domain experts" is that the majority of them are simply executing a process that someone else defined a long time ago. Their definition of "success" is usually that all steps within the process execute successfully without error and they can move on to the next transaction or activity. Very few of them are capable of taking a step back and considering what the process is actually trying t…
If they do, then they by definition become a domain expert. It's just that this takes a while, and projects usually don't give enough time for such to take place unfortunately.
Earlier quoted context omitted.
I recall a spec doc from a domain expert that said something like: "The transaction consists of a credit stub and a debit stub. If the debit stub is missing and is of type X then we do A and if it is of type Y then we do B." How to know what flavour the missing item was? Absolutely no mention of that...
It's interesting that domain experts all exhibit the same cognitive issue - their assumptions are just so ingrained that they cannot articulate it at all. The fact that they "know" a missing stub would have a type is because they actually have some more information than they let on, and this information is only known by the expert. For example, they know if the submission was from party A, it must be type X. But that…
Earlier quoted context omitted.
I agree with you by and large except for this part. > COBOL's promise was ... we wouldn't need programmers anymore..average person doesn't know how to explain & solve a problem COBOL wasn't intended to be used by an "average" person but rather those with deep domain knowledge. They would know the business processes so well that they could transcribe it in COBOL with little or no need to learn how the computers worked…
> COBOL and 4GLs in general COBOL dates back to 1959, much earlier than 4GLs, and the cited 1992/1999 articles make the point that 4GLs were poised to replace the likes of COBOL and FORTRAN when in fact those dinosaurs, or rather nautili since still living, turned out to outlive 4GLs except SQL (when counted as 4GL).
Earlier quoted context omitted.
I asked ChatGPT -- Please estimate the popularity of these languages, relative to the most popular one (that gets 100%). Base your answer on community activity on different platforms (stackoverflow, reddit, hacker news, dev.to, github) and the number of books available and sold: COBOL, Perl, PHP, BASIC, TCL, ColdFusion. Estimated popularity: PHP: 100% (reference) Perl: 30% COBOL: 25% BASIC: 10% TCL: 8% ColdFusion: 5%…
Why php though? Php is as old as java and very popular and constantly updated.
JS is not too pretty either, but I understand many believe it's the only lang the browser understands.
Article starts mentioning 4GL's - a term I have not heard in a long, long time. COBOL's promise was that it was human-like text, so we wouldn't need programmers anymore. A lot like "low code" platforms, and now LLM generated code. The problem is that the average person doesn't know how to explain & solve a problem in sufficient detail to get a working solution. When you get down to breaking down that problem... you b…
I agree with you by and large except for this part. > COBOL's promise was ... we wouldn't need programmers anymore..average person doesn't know how to explain & solve a problem COBOL wasn't intended to be used by an "average" person but rather those with deep domain knowledge. They would know the business processes so well that they could transcribe it in COBOL with little or no need to learn how the computers worked…