Re:Still using assembly?
on
Assembly '03
·
· Score: 1
I'm amazed that people still try to write real software apps using assembly.
The name of the gathering constains the word "assembly" because it was started in the assembly-only democoder days of yore. Many--if not most--entries are no longer written in assembly language. They're written in C, Object Pascal, C++, etc. And they use OpenGL, DirectX, etc.
The best part of the GIMP [gimp.org] is that it is free. For those of us on Windows, the idea of using Photoshop on Linux is cool, but I'd still have to pay for it. Until then, the GIMP is my tool of choice
That's like saying "Cars aren't free, so I will use this bicycle I found next to the dumpster instead." The GIMP may be the best free imaging editing program out there, but don't make the mistake of thinking that equates to "the best imaging editing program out there--period." Because, realistically, it's not even close.
Now, instead of using, and helping improving The GIMP
No offense at all intended, but that's like taking a text editor that someone wrote as a class project and saying "Let's improve it until it's better than Word!" The GIMP was a reasonable attempt at creating an image editing program, but it has deep, deep problems, and is essentially about 20% of Photoshop at best.
In fact, I think we are even nearing the point where home users are going to get seriously pissed off and start demanding lower-power systems...
We're there. No one wants noisy PCs with five fans in them. No wants notebooks that only last two hours on batteries. No one wants a PC that burns up and dies if heat sink silently comes loose or a a fan stops working. No one wants weenie-burning laptops. Well, this isn't true. The hardware fanboys apparently want all of these things.
The trouble is that we've all gotten pretty used to today's ultra-fast CPUs that run bloated crap like Internet Explorer, Visual C++, gcc, KDE, etc. So until someone comes up with a way to keep current speeds and drop power consumption dramatically, then we're in a bit of a muddle. It could happen, though, especially if lower power consumption becomes a higher priority than keeping Moore's law alive. The upcoming Intel Prescott chip might be the straw the breaks the camel's back (twice as many transistors as the P4, yet only 10% faster initially).
Yes pythoners are productive. I just think they would be more so were python staticly typed.
But you don't have any real basis for this, other than your opinion. From your use of the term "pythoners," I'd guess that you don't have extensive experience with the language, so you're really just trying to foist your views on a language community that you're not a part of. Go back and read the Bruce Eckel article I posted a link to in my original reply.
I think creativity also has something to do with it
Oh, come on, you sound like an old man. There are so many good CDs out there that you could buy one a week for the rest of your life and still not hear them all, and that's assuming no more CDs were ever released between now and then. If you don't like pop crap like Mariah Carey and Kid Rock, you don't have to listen to it. But there's so much more out there than that.
1. Writing types is as (or more) error prone than letting the compiler fail on a cast. Ans: Non-sequiter. See ML - I don't have to write types.
You obviously don't know ML. You have to specifically name the constructors for user-defined types. That's essentially the same as having to "write types."
3. Pythoners are productive Ans: python's primitives and libraries are incredibly rich. I'm all for that, but it casts serious doubts on the validity of the assertion that static typing is no good.
What it means is that you obviously don't need static typing in order to be very productive. It begs the question "So exactly what does one need static typing for?"
do some research, GLTRON is another example, I can name about 20 within 20 minutes if I wasn't tired.
Go ahead. One of the all-time stalest game ideas is the so-called "Tron light cycles." Before the version with the Tron name on it showed up in 1982, there were at least half a dozen versions released in the previous five or six years. Then there have been hundreds of versions since then. In fact, it's a standard first game for newbies to write. GLTRON is the same game, but in 3D.
Strong typing: I'm tired of seeing casting errors at runtime.
If your goal is to be pragmatic, then strong typing is not something you want. There is getting to be more evidence that strong typing is a red herring. The people who insist on it get all hot and bothered by languages that don't have strong typing, but it sure isn't keeping other people from being super productive in Python (for example).
I love the concept of indie game development. I dearly do. But look at indie development forums, look at indie game companies, and what do I see: endless reworkings of stale puzzle games, endless reworkings of a certain group, 8-bit games (Boulder Dash, Asteroids, Breakout), clones of Commodore/Atari/Apple favorites that now run on your desktop, and so on. There's also a certain high-end crowd that creates engines that look like Quake II, but without any games on top of them.
Imagine if the independent music scene were like this. All indie bands would be scrambling to record cover versions of small set songs from bands from the early 1980s. And they'd be defending that practice by claiming that there are only a handful of good songs out there, so why write a new one?
It comes as the expense of higher power consumption. Just because we have a better way of dealing with the excess heat doesn't solve the basic problem. It's like saying "I found a way to put an even BIGGER engine in my SUV!" Is that a good thing?
If we ever needed a revolution in CPU manufacturing and design, now is it. It might be optical, it might be something else, but bring it on.
Microsoft rushed ahead with Direct3D in the mid 1990s, made lots of well-publicized mistakes early on because of a general lack of 3D knowledge, then nailed it starting with the graphics side of DirectX 8. The next version, DirectX 9 is a dead-on match for what's generally considered the state of the art in PC video cards. Microsoft isn't even planning DirectX 10, because DX9 is still way beyond what most people need or use (well, that, and the overall decline of the the PC video market). And, believe it or not, DX9 is a breeze to use and has a well-designed API (once you get over the usual COM nonsense that comes with DX in general). Meanwhile, OpenGL, which I'll admit was much better designed from day 1, is going to reach the DX9 level in about five years, if things keep going as they are.
I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.
That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,
In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.
Microsoft has held computers back from the masses. Monopolies charge unreasonably high prices. High prices stop people from buying things. A grindingly competitive software industry would have delivered many more computers to many more people and businesses.
No offense, but that's just silly. The price of the *hardware* is still the main expense of a PC. Now you could argue that IBM PC clones were a total mistake, and that we all should have been using something else, like Amigas or whatnot. But that's not Microsoft's fault. MS-DOS sucked, back in the day. I mean really, really sucked. And at the time there *were* alternatives to buying a generic PC running MS-DOS. But people bought them anyway, even when they were super overpriced and horrifically unusable.
Fast forward to today. Windows is generic. OS X is generic. Linux and BSD are generic. In all honestly, there's little difference between them. They're all bloated, they're all old tech. They're all not as usable as they should be. Again, you can't blame Microsoft for this.
Doesn't matter if no one looks at it
on
Software Archaeology
·
· Score: 0, Offtopic
I'm routinely surprised at how poorly rounded, even in the programming field, many coders are. So many don't know any languages other than C++, Perl, and Python. So many don't know what continuations or closures are. So many don't know what a threaded interpreter is. So many understand garbage collection on more than a polarized, superficial level. So many don't understand how a 60fps video game could be made to work on a 1 MHz home computer. So many think that a compiler is a magical thing that's impossible to implement. So many don't understand how to write software that isn't heavily object-oriented, even when it doesn't need to be. All of this information is out there, but you have to be willing to learn and have an open mind.
I'm seeing a lot of blind flaming about.net, so here's my overall response..net (all lowercase, not ".NET") is Microsoft rearchitecting Windows across the board. You don't use the Win32 API any more; you use the.NET libraries. You don't write applications in raw C++ any more, you use C# or another higher-level language that targets the CLR (Microsoft gave advance information to a number of indepdendent language developers, encouraging them to port their products to.net). Security issues caused by low-level buffer overruns have vanished. You get a nice Visual Basic-like environment for creating GUIs. This is all a great idea.
The downside is that while.NET and C# are much better than the Win32 API and C++, there's a general staidness to it all. It feels like we've moved from 1985 to where we should have been in 1994. C# feels wonderful if you're a C++ programmer who never used Turbo Pascal or Visual Basic (or if you're a Turbo Pascal or Visual Basic programmer annoyed with C++), but it feels overly complex if you've used a dynamic language like Python, Smalltalk, or Lisp. The OOPness of.NET is very heavy and static. And it's all still based on a compile-run cycle, which is hard to go back to once you've gotten away from it.
Personally, even though I think Microsoft is correcting a lot of past mistakes with.NET, and even though Microsoft is showing a lot of initiative and is willing to throw out a lot cruft we've all gotten used to, I don't think it's enough. The result is still complex enough and elaborate enough that it's tough to bank on it as the future.
Latest Mercury numbers indicate that Intel has under 30% graphics market share, and nVidia's integrated solution adds another 9% (half of the total AMD market). Vast majority? It's not even majority!
The GeForce 4 MX is not "nVidia's integrated solution." Sorry. It's the bottom-end card from nVidia that's the default in almost all machines from Dell.
With all the competition these days in the 3D Accelerator market
The vast majority of consumer PCs ship with one of the following:
1. Intel Extreme Graphics 2 (a motherboard chipset roughly equivalent to a TNT2). 2. GeForce 4 MX (essentially GeForce 2 with more fillrate, but without programmable shaders).
The little bit of competition is all at rather small high-end of the market, with nVidia and ATI out diddling each other by a few percent every couple of months. Hardware fanboys excepted, this is uninteresting.
Slashdotters love to make fun of soccer moms driving big, fuel wasting SUVs, then these same people go out and get monster graphics cards that need crazy cooling nonsense. In all honesty, maybe we've crossed the line here? The little benefit these cards are resulting in (remember, 98% of all games still aren't making use of pixel shaders) is not worth all of the energy waste, not to mention all the wasted materials that go into heat sinks and heat pipes and all of that.
First you post a story about Reiser4 without any indication of what Reiser4 is. I read Slashdot regularly, but never heard of it. Then you post a story about Galleon, again without any hit to the reader about what it might be.
With Windows 95, 98, and ME, one or two crashes per day is normal. Sure, it's the *application* that's crashing, but it brings down the operating system with it. I suspect that 5% probably has a lot to do with people playing games under those persions of Windows, or using other less than stable applications. Or it could simply be certain types of video cards. When I had a Voodoo 2 based card running under W95, I had maybe three crashes a day. I also had about the same number of crashes per day when using Linux with that card (though, yes, only the X server crashed, but that was just as bad).
Since I've been using Windows 2000, I haven't had a single crash. Period. Not one. Even when doing heavy software development (multiple compilers running at the same time, etc.).
don't think this has ever been in distpute by anybody. However, it's still far easier to write in C than assembly.
IMO it isn't. Assembly is trivially easy to write. But assemblers have gotten progressively crappier over the years, as much more development effort has been put into C compilers. Even popular assemblers like NASM are barely passable compared to what could be done.
Although the C language has been around for close to 30 years, its appeal has not yet worn off
UNIX is the same age, and it hasn't stopped people from thinking that UNIX-like operating systems are the pinnacle of good design.
Barely about Perl. Certainly not essential.
on
Perl 6 Essentials
·
· Score: 4, Interesting
This book isn't about Perl 6 at all, and there's nothing about it that's "essential." Part of the book is about the *plan* for Perl 6, but that's just plain silly. Who wants to read about the plan for some that's in the middle of development? Odds are that much of this part of the book will be completely invalidated long before Perl 6 is actually released.
The rest of the book--most of the book, actually--is about the Parrot virtual machine. Now, really, does this matter to Perl programmers at all? Is there a book about the innards of the interpreter used for Perl 5? Or a book about Python bytecode? It only matters if you're going to write a compiler that targets Parrot. And, again, note that Parrot is also a work in progress and will likely change dramatically before Perl 6 is actually released.
In short: 1. This is a book about vaporware. 2. Most of the book is not about Perl 6.3. 3. Why did O'Reilly even bother with this?
For certain assembly line tasks, yes, "robots" work. But these are essentially machines that operate completely in patterns. Pick up nut from a perfectly organized stack of nuts. Move N degrees along axis Y, torque nut to 50lbs of pressure. Repeat.
More traditional robotics has hardly advanced at all. Parts are cheaper, sure. But even university research projects, like a robot to push a red ball through a goal, are pretty flaky and unimpressive, and not the kind of thing that would ever work outside of a controlled situation. I'm just not seeing any significant advances.
Slashdot Mirror
I'm amazed that people still try to write real software apps using assembly.
The name of the gathering constains the word "assembly" because it was started in the assembly-only democoder days of yore. Many--if not most--entries are no longer written in assembly language. They're written in C, Object Pascal, C++, etc. And they use OpenGL, DirectX, etc.
The best part of the GIMP [gimp.org] is that it is free. For those of us on Windows, the idea of using Photoshop on Linux is cool, but I'd still have to pay for it. Until then, the GIMP is my tool of choice
That's like saying "Cars aren't free, so I will use this bicycle I found next to the dumpster instead." The GIMP may be the best free imaging editing program out there, but don't make the mistake of thinking that equates to "the best imaging editing program out there--period." Because, realistically, it's not even close.
Now, instead of using, and helping
improving The GIMP
No offense at all intended, but that's like taking a text editor that someone wrote as a class project and saying "Let's improve it until it's better than Word!" The GIMP was a reasonable attempt at creating an image editing program, but it has deep, deep problems, and is essentially about 20% of Photoshop at best.
In fact, I think we are even nearing the point where home users are going to get seriously pissed off and start demanding lower-power systems...
We're there. No one wants noisy PCs with five fans in them. No wants notebooks that only last two hours on batteries. No one wants a PC that burns up and dies if heat sink silently comes loose or a a fan stops working. No one wants weenie-burning laptops. Well, this isn't true. The hardware fanboys apparently want all of these things.
The trouble is that we've all gotten pretty used to today's ultra-fast CPUs that run bloated crap like Internet Explorer, Visual C++, gcc, KDE, etc. So until someone comes up with a way to keep current speeds and drop power consumption dramatically, then we're in a bit of a muddle. It could happen, though, especially if lower power consumption becomes a higher priority than keeping Moore's law alive. The upcoming Intel Prescott chip might be the straw the breaks the camel's back (twice as many transistors as the P4, yet only 10% faster initially).
Yes pythoners are productive. I just think they would be more so were python staticly typed.
But you don't have any real basis for this, other than your opinion. From your use of the term "pythoners," I'd guess that you don't have extensive experience with the language, so you're really just trying to foist your views on a language community that you're not a part of. Go back and read the Bruce Eckel article I posted a link to in my original reply.
I think creativity also has something to do with it
Oh, come on, you sound like an old man. There are so many good CDs out there that you could buy one a week for the rest of your life and still not hear them all, and that's assuming no more CDs were ever released between now and then. If you don't like pop crap like Mariah Carey and Kid Rock, you don't have to listen to it. But there's so much more out there than that.
1. Writing types is as (or more) error prone than letting the compiler fail on a cast.
Ans: Non-sequiter. See ML - I don't have to write types.
You obviously don't know ML. You have to specifically name the constructors for user-defined types. That's essentially the same as having to "write types."
3. Pythoners are productive
Ans: python's primitives and libraries are incredibly rich. I'm all for that, but it casts serious doubts on the validity of the assertion that static typing is no good.
What it means is that you obviously don't need static typing in order to be very productive. It begs the question "So exactly what does one need static typing for?"
do some research, GLTRON is another example, I can name about 20 within 20 minutes if I wasn't tired.
Go ahead. One of the all-time stalest game ideas is the so-called "Tron light cycles." Before the version with the Tron name on it showed up in 1982, there were at least half a dozen versions released in the previous five or six years. Then there have been hundreds of versions since then. In fact, it's a standard first game for newbies to write. GLTRON is the same game, but in 3D.
Strong typing: I'm tired of seeing casting errors at runtime.
If your goal is to be pragmatic, then strong typing is not something you want. There is getting to be more evidence that strong typing is a red herring. The people who insist on it get all hot and bothered by languages that don't have strong typing, but it sure isn't keeping other people from being super productive in Python (for example).
Here's a good read.
I love the concept of indie game development. I dearly do. But look at indie development forums, look at indie game companies, and what do I see: endless reworkings of stale puzzle games, endless reworkings of a certain group, 8-bit games (Boulder Dash, Asteroids, Breakout), clones of Commodore/Atari/Apple favorites that now run on your desktop, and so on. There's also a certain high-end crowd that creates engines that look like Quake II, but without any games on top of them.
Imagine if the independent music scene were like this. All indie bands would be scrambling to record cover versions of small set songs from bands from the early 1980s. And they'd be defending that practice by claiming that there are only a handful of good songs out there, so why write a new one?
It comes as the expense of higher power consumption. Just because we have a better way of dealing with the excess heat doesn't solve the basic problem. It's like saying "I found a way to put an even BIGGER engine in my SUV!" Is that a good thing?
If we ever needed a revolution in CPU manufacturing and design, now is it. It might be optical, it might be something else, but bring it on.
Microsoft rushed ahead with Direct3D in the mid 1990s, made lots of well-publicized mistakes early on because of a general lack of 3D knowledge, then nailed it starting with the graphics side of DirectX 8. The next version, DirectX 9 is a dead-on match for what's generally considered the state of the art in PC video cards. Microsoft isn't even planning DirectX 10, because DX9 is still way beyond what most people need or use (well, that, and the overall decline of the the PC video market). And, believe it or not, DX9 is a breeze to use and has a well-designed API (once you get over the usual COM nonsense that comes with DX in general). Meanwhile, OpenGL, which I'll admit was much better designed from day 1, is going to reach the DX9 level in about five years, if things keep going as they are.
I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.
That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,
In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.
Microsoft has held computers back from the masses. Monopolies charge unreasonably high prices. High prices stop people from buying things. A grindingly competitive software industry would have delivered many more computers to many more people and businesses.
No offense, but that's just silly. The price of the *hardware* is still the main expense of a PC. Now you could argue that IBM PC clones were a total mistake, and that we all should have been using something else, like Amigas or whatnot. But that's not Microsoft's fault. MS-DOS sucked, back in the day. I mean really, really sucked. And at the time there *were* alternatives to buying a generic PC running MS-DOS. But people bought them anyway, even when they were super overpriced and horrifically unusable.
Fast forward to today. Windows is generic. OS X is generic. Linux and BSD are generic. In all honestly, there's little difference between them. They're all bloated, they're all old tech. They're all not as usable as they should be. Again, you can't blame Microsoft for this.
I'm routinely surprised at how poorly rounded, even in the programming field, many coders are. So many don't know any languages other than C++, Perl, and Python. So many don't know what continuations or closures are. So many don't know what a threaded interpreter is. So many understand garbage collection on more than a polarized, superficial level. So many don't understand how a 60fps video game could be made to work on a 1 MHz home computer. So many think that a compiler is a magical thing that's impossible to implement. So many don't understand how to write software that isn't heavily object-oriented, even when it doesn't need to be. All of this information is out there, but you have to be willing to learn and have an open mind.
I'm seeing a lot of blind flaming about .net, so here's my overall response. .net (all lowercase, not ".NET") is Microsoft rearchitecting Windows across the board. You don't use the Win32 API any more; you use the .NET libraries. You don't write applications in raw C++ any more, you use C# or another higher-level language that targets the CLR (Microsoft gave advance information to a number of indepdendent language developers, encouraging them to port their products to .net). Security issues caused by low-level buffer overruns have vanished. You get a nice Visual Basic-like environment for creating GUIs. This is all a great idea.
.NET and C# are much better than the Win32 API and C++, there's a general staidness to it all. It feels like we've moved from 1985 to where we should have been in 1994. C# feels wonderful if you're a C++ programmer who never used Turbo Pascal or Visual Basic (or if you're a Turbo Pascal or Visual Basic programmer annoyed with C++), but it feels overly complex if you've used a dynamic language like Python, Smalltalk, or Lisp. The OOPness of .NET is very heavy and static. And it's all still based on a compile-run cycle, which is hard to go back to once you've gotten away from it.
.NET, and even though Microsoft is showing a lot of initiative and is willing to throw out a lot cruft we've all gotten used to, I don't think it's enough. The result is still complex enough and elaborate enough that it's tough to bank on it as the future.
The downside is that while
Personally, even though I think Microsoft is correcting a lot of past mistakes with
Latest Mercury numbers indicate that Intel has under 30% graphics market share, and nVidia's integrated solution adds another 9% (half of the total AMD market). Vast majority? It's not even majority!
The GeForce 4 MX is not "nVidia's integrated solution." Sorry. It's the bottom-end card from nVidia that's the default in almost all machines from Dell.
With all the competition these days in the 3D Accelerator market
The vast majority of consumer PCs ship with one of the following:
1. Intel Extreme Graphics 2 (a motherboard chipset roughly equivalent to a TNT2).
2. GeForce 4 MX (essentially GeForce 2 with more fillrate, but without programmable shaders).
The little bit of competition is all at rather small high-end of the market, with nVidia and ATI out diddling each other by a few percent every couple of months. Hardware fanboys excepted, this is uninteresting.
Slashdotters love to make fun of soccer moms driving big, fuel wasting SUVs, then these same people go out and get monster graphics cards that need crazy cooling nonsense. In all honesty, maybe we've crossed the line here? The little benefit these cards are resulting in (remember, 98% of all games still aren't making use of pixel shaders) is not worth all of the energy waste, not to mention all the wasted materials that go into heat sinks and heat pipes and all of that.
First you post a story about Reiser4 without any indication of what Reiser4 is. I read Slashdot regularly, but never heard of it. Then you post a story about Galleon, again without any hit to the reader about what it might be.
With Windows 95, 98, and ME, one or two crashes per day is normal. Sure, it's the *application* that's crashing, but it brings down the operating system with it. I suspect that 5% probably has a lot to do with people playing games under those persions of Windows, or using other less than stable applications. Or it could simply be certain types of video cards. When I had a Voodoo 2 based card running under W95, I had maybe three crashes a day. I also had about the same number of crashes per day when using Linux with that card (though, yes, only the X server crashed, but that was just as bad).
Since I've been using Windows 2000, I haven't had a single crash. Period. Not one. Even when doing heavy software development (multiple compilers running at the same time, etc.).
don't think this has ever been in distpute by anybody. However, it's still far easier to write in C than assembly.
IMO it isn't. Assembly is trivially easy to write. But assemblers have gotten progressively crappier over the years, as much more development effort has been put into C compilers. Even popular assemblers like NASM are barely passable compared to what could be done.
Although the C language has been around for close to 30 years, its appeal has not yet worn off
UNIX is the same age, and it hasn't stopped people from thinking that UNIX-like operating systems are the pinnacle of good design.
This book isn't about Perl 6 at all, and there's nothing about it that's "essential." Part of the book is about the *plan* for Perl 6, but that's just plain silly. Who wants to read about the plan for some that's in the middle of development? Odds are that much of this part of the book will be completely invalidated long before Perl 6 is actually released.
The rest of the book--most of the book, actually--is about the Parrot virtual machine. Now, really, does this matter to Perl programmers at all? Is there a book about the innards of the interpreter used for Perl 5? Or a book about Python bytecode? It only matters if you're going to write a compiler that targets Parrot. And, again, note that Parrot is also a work in progress and will likely change dramatically before Perl 6 is actually released.
In short:
1. This is a book about vaporware.
2. Most of the book is not about Perl 6.3.
3. Why did O'Reilly even bother with this?
For certain assembly line tasks, yes, "robots" work. But these are essentially machines that operate completely in patterns. Pick up nut from a perfectly organized stack of nuts. Move N degrees along axis Y, torque nut to 50lbs of pressure. Repeat.
More traditional robotics has hardly advanced at all. Parts are cheaper, sure. But even university research projects, like a robot to push a red ball through a goal, are pretty flaky and unimpressive, and not the kind of thing that would ever work outside of a controlled situation. I'm just not seeing any significant advances.