Maybe they realized I don't need a penal enlargement and don't want to meet women (I'm married)?
So you're saying, basically, that having married a woman, you've realized you don't like them, and that this situation has been punishing enough that onlookers take pity on you rather than giving you a hard time?
I'm happy to say my marriage hasn't had that effect...
It seems that if Linux were available as a free alternative in every PC shipped, it could provide a longer life to products that could be shared ( like hand me down clothes ) to younger siblings or new users to make the best use of the effort of creating machines and the least toxic landfill.
You think we're going to have hand-me-down clothes that run Linux within the next three years?
I mean, I could see maybe new clothes having this kind of capability in that time... but old stuff?
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
I contend that the "encode everything as a string" mentality was an asset, due to computer limitations in the time period in which the convention started
Encoding everything as a string was done due to human limitations, not computer limitations. Computer limitations of the time were used to argue against this form of simplification, although in many cases these arguments were unconvincing(much like the similar arguments of today).
The computer limitations at the time required a particular level of compromise between lack of complexity in the solution and space-and-time efficiency. But, while the text formats were bulky and inefficient, the tools that processed them could be relatively simple - requiring little more than the standard C library.
Nowadays, we don't need that level of space-efficiency on the code being run. For instance, in the 1970s and 1980s you could safely assume a Unix system would have the standard C library and some reasonably standard system calls. Nowadays, it's a safe bet a Unix system has at least on XML lib. If XML or another similarly capable (and hopefully more efficient) format were taken as a shell-level assumption for process-to-process exchange, then writing the tools that run in the shell would be no more complex, and writing shell code to translate one process's XML output to another process's XML input would be simpler than the equivalent translation done today (with the first process's ad-hoc text output format and the second process's ad-hoc text input format...) If the shell at least has a pretty good idea of the structure of the data that's likely to come over the stream, then it can provide support in the language to help you translate data.
"Unconvincing arguments" depend on who needs convincing - and who's doing the arguing. Sadly, I am not as good at debate as I should be, if I want to advocate this kind of change. This is part of the reason I take up this argument from time to time, and debate it with anyone who's willing - to fill gaps in my knowledge and to learn how to argue my case better.
but these days I think it's pretty limiting.
Limitations are often an asset. It was limiting back then, and purposefully so.
Limiting the conceptual complexity of your interface is an asset. Limiting the programmatic complexity of coding for your environment is an asset. The problem is that any kind of limitation is also a trade-off in terms of power.
The Unix shell makes minimal assumptions about the format of data that goes over pipes. This is an asset in a sense - it is flexible and it is simple to implement. Where this limitation becomes a problem is in the burden it places on the people using the shell. The concept behind Unix Shell as a scripting language was to have a large number of small tools, each fairly simple in concept and limited in scope - and to have these tools work together. The problem is that when you make no assumptions about what goes over the stream, then every tool incorporating a serialize/deserialize step must come up with a serialization format - usually these don't match because the programmers each came up with a format that worked for their own tool. The shell can't provide much in the way of help translating between formats because no assumptions are made even about what kind of formats are even likely to go over the stream.
Making XML (or a more efficient format with similar capabilities) an assumption in the Unix Shell and all standard Unix tools would be one solution - the reason I favor a binary format rather than XML (or, perhaps, a binary encoding of XML) for this job is because text-encoded XML doesn't really gain the user anything. In the processing steps the user won't see XML, and when viewing output, you don't want a raw XML dump anyway - as lo
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
You've ignored the fact that for any two tools to work together, their assumptions about the structure with which data is encoded over the stream have to match.
Dude, it is up to the programmer to format the data properly, including any escaping when piping strings from one proggie to another.
Yes, that's precisely my complaint. Even the simplest exchange of structured data between two processes on a typical shell requires this kind of attention.
Shell scripts aren't supposed to replace more robust programming languages.
Why not? The way I see it, half these "more robust programming languages" used by Unix users were introduced to get around limitations of the shell. (Perl being the prime example - though calling it "robust" is arguable...)
I think it silly to want to parse XML via shell scripts, BUT, a shell script could pull useful data from an XML file.
Pulling data out of an XML file means parsing XML data.
My point was not to say that bash can't parse XML or that it should - the point is that it's not one well suited for handling problems of that complexity. You need shell-level support either for objects or streamable data structures so your XML-wrangling tools - so that the XML parser could either be interrogated (as an object) about the XML contents or dump out the contents (as a data structure).
So let me state the obvious, find the right tool for the job rather than thinking everyones tries to shoe horn everything into the same tool.
The idea of a Unix shell is to support different tools working together: small, single-purpose tools chained together to tackle larger problems. In that capacity it is failing - the complexity of passing data between these "small tools" makes it needlessly difficult to implement a module to do a job as a shell program on the PATH. So to avoid all that hassle people write Perl or Python modules instead.
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
Sounds like a problem with bash more than anything
ksh93 can parse XML plenty fine
And that's great. But I'm not talking just about the ability to parse XML - I'm talking about the ability to extend the shell to handle a problem like parsing XML - and what you can do with that data once the parsing is done.
In scripting languages like Perl or Python - you have datatypes supported by the language, recognized by all modules written for that language - so you've got a lot of power in terms of what a newly-added module can do, and how it can interact with other modules. But then when you want to communicate with another process, the problem of data exchange becomes rather more complicated... The same is generally true in shells as well - the shell language itself may have a somewhat reasonable set of datatypes (bash has arrays at least - IIRC another shell, ksh maybe, provides associative arrays) but when it comes to passing this structured data elsewhere, you're pretty much stuck.
Given that the whole idea of the shell is supposed to be about stringing together little tools to do different parts of a bigger job, this stifled communication is, as far as I'm concerned, a big problem. You only get the full programming capabilities out of your shell when you're working with different shell modules running in the same shell. Code running in two different shell instances, or code interacting with another process has to deal with the "minimal assumptions" of shell data streaming and process invocation.
"action figures.. like Baby Jabba Hutt and Jabba the Hutt's Gay Uncle may have taken the franchise a bridge too far."
Yes, a bridge too far over a tank of sharks.
I understand the "jumped the shark" think is considered out of date these days. You might consider going with "nuked the fridge" instead, which is looking like a promising contemporary alternative...
Though, honestly, I think if you want to talk about a franchise getting pushed too far, talk to Stallone. Maybe Schwarzenegger, too - he was looking kind of dumpy in "Terminator 3" but Stallone, with Rocky and Rambo...
He is right on about the quotes. I've seen all the "new" star wars movies at least twice and right now I can't think of a single memorable line from any of them.
Bah! Allow me to step off your lawn and educate you!
Who can forget the classic "Around the survivors a perimeter create"? The tender emotion of "I hate sand"? The comic mischief of C-3PO's "I'm beside myself!"? Or those wacky merchants lamenting, "We will not survive this!" and "We should not have made this bargain!" Or Obi-Wan's quip about blasters being "so uncivilized" after his desperate life-or-death battle with Grievous... Or how about "You don't want to sell me death sticks. You want to go home and rethink your life." when Obi Wan is in the bar? And don't forget, the dramatic pinnacle of the movie, after Anakin discovers Padme is dead and he's been turned into a cyborg: as he curses the heavens, screaming "DO NOT WANT!"
And now they have a Force Unleashed game coming out where they amp up the Force powers until it's like frickin' Dragonball Z. All that's missing is Vegeta screaming "HIS POWER LEVELS ARE 9000??!!!"
I so wish I was a villein for Dragon Ball Z. When they take 8 episodes to through their power attack. I just wont sit there and marvel at their method or their power level. I would just take a gun and shoot him.
Yeah, that never seemed to work out real well when it happened in Dragonball and DBZ... Raditz caught the bullet that was shot at him and threw it back at the guy who fired it and killed him... And Goku was able to dodge bullets since he was like 12 years old...
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
From what I've seen (not used it) the new Windows PowerShell (Monad) is designed around "piping" data between apps that actually exchange.Net objects, including lists, maps, etc. of objects -- rather than character streams. There seem to be generic commands that provide sql-like "select / where" filtering clauses, etc., too. You might explore that, see if it fits your needs. It looks awfully verbose to me though, I'd have to find a way to set aliases for most everything. Just a thought.
Yeah, I learned about Monad a few years back, and have tried Powershell, briefly anyway - it's definitely interesting but various things about it don't really suit my tastes. I'm trying to come up with something that does.
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 4, Interesting
The lack of structured data and live objects is a feature, not a bug. The fact that everything is a string, and that everything can be piped between all the different commands means that you can string together commands in new and exciting ways that nobody ever thought was possible. Making all the commands pass around different types of objects means that all the other commands have to be aware of all these other datatypes, and have to know how to handle them.
This is true of textual data as well - you're simply glossing over the complexity of serializing and re-parsing any non-trivial data structure in textual form... You've ignored the fact that for any two tools to work together, their assumptions about the structure with which data is encoded over the stream have to match.
See, if your text-encoded data is simple enough that you can simply choose a character as a field delimiter and another as a record separator, it's easy to split your data into individual records and fields again. It gets a little harder if you want to provide for the possibility that your records may actually contain the delimiter characters (then you're into parsing - at least enough parsing to distinguish between an escaped character and an unescaped one) Setting up the format so you can really encapsulate anything - that reaches the point where it's worth having a tool whose only job is interfacing with this format...
The problem here is that normally when you want to interpret some encoded form of a piece of data, you first translate it into something that's easier to work with. But in BASH (and most CLI shells, I believe) there is no "more convenient form" to which you can readily translate any moderately complex structure. (Consider, for instance, how you would implement an XML parser for Bash - as an external command it simply wouldn't work... it'd have to be done as a Bash plug-in module, and even then its capabilities would be limited. And then suppose you want to filter the parsed data and pass it to another process? You've got to re-encode it, and then the next process has to know how to decode this encoding (probably still XML) as well...
I contend that the "encode everything as a string" mentality was an asset, due to computer limitations in the time period in which the convention started - but these days I think it's pretty limiting.
If you want something with objects and structured data in the shell, then there's MS PowerShell. But maybe there's a reason it hasn't caught on yet.
I think Powershell has been progressing (in terms of popularity, I mean) quite satisfactorily... The reason it hasn't caught on with me, however, is 'cause I want a Unix solution (that is, runs on Unix, and fairly Unix-styled), not a Windows one - and while I agree with the logic behind some of their design decisions (like the verb-noun convention for command names) I don't like the consequences (the language is much too verbose for my tastes...)
I think it's a step in the right direction but not quite what I'm looking for.
Assuming Powershell hasn't been embraced and taking that as a sign that one particular facet of its design was a bad idea is pretty laughable. Any new tool takes time to be adopted - and Powershell is a tool for a fairly small niche - CLI users on Windows.
Re:Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
Most data translation projects don't need advanced data structures to get the work done. This common misconception is responsible for a great deal of the software project failures over the last few decades.
I'm just talking about basic data structures here - support for anything beyond strings or text streams. Shell programming has become mired in translation steps. Scripting languages let you avoid all that because the language provides data structures and objects, as well as a reasonable set of baseline data types, which modules written in the language can work with.
Some shells support some data structures and containers, but I think Powershell is the only one right now that can actually pass these between processes...
Shell as a scripting language...
on
Bash Cookbook
·
· Score: 1
Now, here's what I'd like to know...
Are you serious here, showing that both shells support useful features, or are you being facetious, showing that both shells are merely acceptable stepping-stones to run Perl code?
I love CLIs but my feeling on most of them is that they're more than a little archaic - the lack of any non-trivial datatypes (and particularly the lack of support for passing structured data or live objects between shell processes) makes it needlessly difficult to get things done - I believe that is one of the major reasons people script with scripting languages these days instead of shells...
"feint" of heart?
on
Bash Cookbook
·
· Score: 4, Funny
So, what, does this refer to people who act like they're going to rip your heart out of your chest, only it all turns out to be a ruse so they can kick you in the balls?
Do you propose I play with it in a balloon indoors? If I get arrested for doing something stupid, I'd feel a little better knowing my family won't get soaked in the next rainstorm because I blew the roof off the house.
The above is pretty funny, for certain values of "it"... I mean, you soaked your family? Blew the roof off the house?? Dude...
There is some fantasy among environmentalists that envisions herds of cattle trampling wheat and corn fields.
In my fantasy, after the cattle trample the wheat and corn fields, vegetables would be grown in place of the grains...
"If only we could stop breeding those cows, there'd be food for everyone!" The best beef comes from herds of cows running around on rocky, inhospitable land, eking out an existence eating scrub grass and brambles.
"The best beef" isn't the same thing as "the majority of beef". Most of the beef people are eating isn't "the best beef", and it's not free-range grass-fed beef.
What I object to is the excess of cattle farming. Not cattle farming in general, just the irresponsible practices brought about largely because of our taste for excess.
Farming is a low-profit-margin industry - you don't waste a lot of money buying/hoarding lots of human-edible food to feed your cows.
Well, actually we do waste a lot of money buying and hoarding lots of human-edible food: corn, mostly. The price of the crop is unnaturally reduced by subsidies and the large supply on hand - as a result it's cheap enough to feed to cows to grow beef with. It's not particularly nutritious, though...
Not as such... But it can make the cup, and it could even fill it with something that's almost, but not quite, entirely unlike tea.
The real trick, as I understand it, is to have "tea" and "no tea" at the same time. This goes against common sense, though, so I'm not sure how it could be possible.
But on the other hand - to think of something that would today be a garage kit, only done up as a downloadable design for fabrication... that would be pretty damn cool.
Agreed. But look at the dark side... IP laws are going to apply to this new medium too. Fox or whoever owns the copyrights isn't going to let you sell that Serenity kit even if you created the CAD files as a labor of love.
This is exactly the situation we have today. People who want to sell garage kits of their favorite copyrighted subjects have two options, basically - the first option is to get the kit properly licensed - which actually is practical in some cases. (For instance, an event-only license to sell a kit at Wonder Fest in Japan is pretty reasonable, I hear... There's also the resin Falke that was released a year or two ago, that kit was produced as a garage kit and then officially licensed...)
The second option is to simply "fly under the radar". Keep your operation small, hope you don't get pinched, and cease and desist if so requested. In this category you'll find all sorts of Gundam, Star Wars, Star Trek, etc. And the Serenity...
Of course, part of the reason, I expect, why GKs are allowed to exist is because it's not profitable for a large-scale operation to pursue every last opportunity with the license. Only so many people are going to want a Ferengi pod, or the Klingon cruiser from Star Trek: The Motion Picture (not the Bird of Prey from Trek 3, which tends to be more popular, or the simpler D-7 from the TV series...) Let alone a conversion kit for some obscure variant most people have never heard of... There's just not enough benefit to justify the expense of chasing down all the little GK operations. That, too, may change - since affordable home fabrication would make it trivial to do small production runs affordably, the only concern would be making enough money to cover the costs of developing the pattern... But if that means kit makers can sell a wider variety of designs in the form of fabrication designs, all the better...
3D printing would make that hobby much easier - and obsolete.
How do you figure?
I mean, right now, the model-building hobby is "obsolete" for any number of reasons. Resin Figure kits are obsolete due to high-quality pre-painted polyvinyl, or pre-painted resin products. Injection kits are sold pre-painted, too. Even kits without such gimmicks are generally of such high quality these days that modelers joke that you can "toss in some glue and shake the box" and have a winning model... Some even argue that the whole reliance upon kits has killed modelers' potential to learn "true modeling" - AKA scratch building...
3-D printing does not presently do anything to make modeling obsolete. At some point it will advance far enough that there'll be nothing left to do once the part is printed. But it's a long way from here to there. In the mean time, there will be this new capability, home fabrication, but to really exploit it (produce display pieces from raw fabricated parts) people will have to turn to modeling skills... That's what interests me.
Well, at $50-100 per part according to TFS, a 200-part kit is going to set you back a pretty penny.
Did you not get the part where I'm talking about the future potential of 3-D printing? Do you really think it's always going to be as expensive as it is now?
IMO, 3D printing solves one problem (generating copies of a design) but not the other (creating the design in the first place).
I've done a little bit of computer modeling and a fair bit of scratch-building - certainly there are things that are perfectly simple to do by hand, not worth complicating the process by introducing a computer-design phase... And there's inherent limitations in current display and input technologies that make it difficult to model on the computer, even with the right tools...
But on the other hand, I've basically finished my computer-modeled Zaku, but the process of making the corresponding physical parts has been very slow. Maybe this says more about my lack of skill at scratch building than it does about the relative ease of computer modeling, I don't know... But either way, once a model design is on the computer, cheap fabrication would mean cheap production and flexible distribution... A great thing for people who want to have kits, I bet - probably not so great for people who want to sell them.:D
I am aware that 3-D printed parts are already a present-day reality - what I'm looking forward to is a point when it's as cheap and accessible as papercraft is today.
Slashdot Mirror
Maybe they realized I don't need a penal enlargement and don't want to meet women (I'm married)?
So you're saying, basically, that having married a woman, you've realized you don't like them, and that this situation has been punishing enough that onlookers take pity on you rather than giving you a hard time?
I'm happy to say my marriage hasn't had that effect...
Ok so, right now its 2008. Since when does 8+3=12?
OK, fine... three and a half years... Happy?
It seems that if Linux were available as a free alternative in every PC shipped, it could provide a longer life to products that could be shared ( like hand me down clothes ) to younger siblings or new users to make the best use of the effort of creating machines and the least toxic landfill.
You think we're going to have hand-me-down clothes that run Linux within the next three years?
I mean, I could see maybe new clothes having this kind of capability in that time... but old stuff?
Encoding everything as a string was done due to human limitations, not computer limitations. Computer limitations of the time were used to argue against this form of simplification, although in many cases these arguments were unconvincing(much like the similar arguments of today).
The computer limitations at the time required a particular level of compromise between lack of complexity in the solution and space-and-time efficiency. But, while the text formats were bulky and inefficient, the tools that processed them could be relatively simple - requiring little more than the standard C library.
Nowadays, we don't need that level of space-efficiency on the code being run. For instance, in the 1970s and 1980s you could safely assume a Unix system would have the standard C library and some reasonably standard system calls. Nowadays, it's a safe bet a Unix system has at least on XML lib. If XML or another similarly capable (and hopefully more efficient) format were taken as a shell-level assumption for process-to-process exchange, then writing the tools that run in the shell would be no more complex, and writing shell code to translate one process's XML output to another process's XML input would be simpler than the equivalent translation done today (with the first process's ad-hoc text output format and the second process's ad-hoc text input format...) If the shell at least has a pretty good idea of the structure of the data that's likely to come over the stream, then it can provide support in the language to help you translate data.
"Unconvincing arguments" depend on who needs convincing - and who's doing the arguing. Sadly, I am not as good at debate as I should be, if I want to advocate this kind of change. This is part of the reason I take up this argument from time to time, and debate it with anyone who's willing - to fill gaps in my knowledge and to learn how to argue my case better.
Limitations are often an asset. It was limiting back then, and purposefully so.
Limiting the conceptual complexity of your interface is an asset. Limiting the programmatic complexity of coding for your environment is an asset. The problem is that any kind of limitation is also a trade-off in terms of power.
The Unix shell makes minimal assumptions about the format of data that goes over pipes. This is an asset in a sense - it is flexible and it is simple to implement. Where this limitation becomes a problem is in the burden it places on the people using the shell. The concept behind Unix Shell as a scripting language was to have a large number of small tools, each fairly simple in concept and limited in scope - and to have these tools work together. The problem is that when you make no assumptions about what goes over the stream, then every tool incorporating a serialize/deserialize step must come up with a serialization format - usually these don't match because the programmers each came up with a format that worked for their own tool. The shell can't provide much in the way of help translating between formats because no assumptions are made even about what kind of formats are even likely to go over the stream.
Making XML (or a more efficient format with similar capabilities) an assumption in the Unix Shell and all standard Unix tools would be one solution - the reason I favor a binary format rather than XML (or, perhaps, a binary encoding of XML) for this job is because text-encoded XML doesn't really gain the user anything. In the processing steps the user won't see XML, and when viewing output, you don't want a raw XML dump anyway - as lo
You've ignored the fact that for any two tools to work together, their assumptions about the structure with which data is encoded over the stream have to match.
Dude, it is up to the programmer to format the data properly, including any escaping when piping strings from one proggie to another.
Yes, that's precisely my complaint. Even the simplest exchange of structured data between two processes on a typical shell requires this kind of attention.
Shell scripts aren't supposed to replace more robust programming languages.
Why not? The way I see it, half these "more robust programming languages" used by Unix users were introduced to get around limitations of the shell. (Perl being the prime example - though calling it "robust" is arguable...)
I think it silly to want to parse XML via shell scripts, BUT, a shell script could pull useful data from an XML file.
Pulling data out of an XML file means parsing XML data.
My point was not to say that bash can't parse XML or that it should - the point is that it's not one well suited for handling problems of that complexity. You need shell-level support either for objects or streamable data structures so your XML-wrangling tools - so that the XML parser could either be interrogated (as an object) about the XML contents or dump out the contents (as a data structure).
So let me state the obvious, find the right tool for the job rather than thinking everyones tries to shoe horn everything into the same tool.
The idea of a Unix shell is to support different tools working together: small, single-purpose tools chained together to tackle larger problems. In that capacity it is failing - the complexity of passing data between these "small tools" makes it needlessly difficult to implement a module to do a job as a shell program on the PATH. So to avoid all that hassle people write Perl or Python modules instead.
Sounds like a problem with bash more than anything
ksh93 can parse XML plenty fine
And that's great. But I'm not talking just about the ability to parse XML - I'm talking about the ability to extend the shell to handle a problem like parsing XML - and what you can do with that data once the parsing is done.
In scripting languages like Perl or Python - you have datatypes supported by the language, recognized by all modules written for that language - so you've got a lot of power in terms of what a newly-added module can do, and how it can interact with other modules. But then when you want to communicate with another process, the problem of data exchange becomes rather more complicated... The same is generally true in shells as well - the shell language itself may have a somewhat reasonable set of datatypes (bash has arrays at least - IIRC another shell, ksh maybe, provides associative arrays) but when it comes to passing this structured data elsewhere, you're pretty much stuck.
Given that the whole idea of the shell is supposed to be about stringing together little tools to do different parts of a bigger job, this stifled communication is, as far as I'm concerned, a big problem. You only get the full programming capabilities out of your shell when you're working with different shell modules running in the same shell. Code running in two different shell instances, or code interacting with another process has to deal with the "minimal assumptions" of shell data streaming and process invocation.
"action figures.. like Baby Jabba Hutt and Jabba the Hutt's Gay Uncle may have taken the franchise a bridge too far."
Yes, a bridge too far over a tank of sharks.
I understand the "jumped the shark" think is considered out of date these days. You might consider going with "nuked the fridge" instead, which is looking like a promising contemporary alternative...
Though, honestly, I think if you want to talk about a franchise getting pushed too far, talk to Stallone. Maybe Schwarzenegger, too - he was looking kind of dumpy in "Terminator 3" but Stallone, with Rocky and Rambo...
He is right on about the quotes. I've seen all the "new" star wars movies at least twice and right now I can't think of a single memorable line from any of them.
Bah! Allow me to step off your lawn and educate you!
Who can forget the classic "Around the survivors a perimeter create"? The tender emotion of "I hate sand"? The comic mischief of C-3PO's "I'm beside myself!"? Or those wacky merchants lamenting, "We will not survive this!" and "We should not have made this bargain!" Or Obi-Wan's quip about blasters being "so uncivilized" after his desperate life-or-death battle with Grievous... Or how about "You don't want to sell me death sticks. You want to go home and rethink your life." when Obi Wan is in the bar? And don't forget, the dramatic pinnacle of the movie, after Anakin discovers Padme is dead and he's been turned into a cyborg: as he curses the heavens, screaming "DO NOT WANT!"
Judge him by his size, do you? Size matters not!
When 900 years old you reach, look as good, you will not...
And now they have a Force Unleashed game coming out where they amp up the Force powers until it's like frickin' Dragonball Z. All that's missing is Vegeta screaming "HIS POWER LEVELS ARE 9000??!!!"
...or 8000 in the original...
I so wish I was a villein for Dragon Ball Z. When they take 8 episodes to through their power attack. I just wont sit there and marvel at their method or their power level. I would just take a gun and shoot him.
Yeah, that never seemed to work out real well when it happened in Dragonball and DBZ... Raditz caught the bullet that was shot at him and threw it back at the guy who fired it and killed him... And Goku was able to dodge bullets since he was like 12 years old...
From what I've seen (not used it) the new Windows PowerShell (Monad) is designed around "piping" data between apps that actually exchange .Net objects, including lists, maps, etc. of objects -- rather than character streams. There seem to be generic commands that provide sql-like "select / where" filtering clauses, etc., too. You might explore that, see if it fits your needs. It looks awfully verbose to me though, I'd have to find a way to set aliases for most everything. Just a thought.
Yeah, I learned about Monad a few years back, and have tried Powershell, briefly anyway - it's definitely interesting but various things about it don't really suit my tastes. I'm trying to come up with something that does.
The lack of structured data and live objects is a feature, not a bug. The fact that everything is a string, and that everything can be piped between all the different commands means that you can string together commands in new and exciting ways that nobody ever thought was possible. Making all the commands pass around different types of objects means that all the other commands have to be aware of all these other datatypes, and have to know how to handle them.
This is true of textual data as well - you're simply glossing over the complexity of serializing and re-parsing any non-trivial data structure in textual form... You've ignored the fact that for any two tools to work together, their assumptions about the structure with which data is encoded over the stream have to match.
See, if your text-encoded data is simple enough that you can simply choose a character as a field delimiter and another as a record separator, it's easy to split your data into individual records and fields again. It gets a little harder if you want to provide for the possibility that your records may actually contain the delimiter characters (then you're into parsing - at least enough parsing to distinguish between an escaped character and an unescaped one) Setting up the format so you can really encapsulate anything - that reaches the point where it's worth having a tool whose only job is interfacing with this format...
The problem here is that normally when you want to interpret some encoded form of a piece of data, you first translate it into something that's easier to work with. But in BASH (and most CLI shells, I believe) there is no "more convenient form" to which you can readily translate any moderately complex structure. (Consider, for instance, how you would implement an XML parser for Bash - as an external command it simply wouldn't work... it'd have to be done as a Bash plug-in module, and even then its capabilities would be limited. And then suppose you want to filter the parsed data and pass it to another process? You've got to re-encode it, and then the next process has to know how to decode this encoding (probably still XML) as well...
I contend that the "encode everything as a string" mentality was an asset, due to computer limitations in the time period in which the convention started - but these days I think it's pretty limiting.
If you want something with objects and structured data in the shell, then there's MS PowerShell. But maybe there's a reason it hasn't caught on yet.
I think Powershell has been progressing (in terms of popularity, I mean) quite satisfactorily... The reason it hasn't caught on with me, however, is 'cause I want a Unix solution (that is, runs on Unix, and fairly Unix-styled), not a Windows one - and while I agree with the logic behind some of their design decisions (like the verb-noun convention for command names) I don't like the consequences (the language is much too verbose for my tastes...)
I think it's a step in the right direction but not quite what I'm looking for.
Assuming Powershell hasn't been embraced and taking that as a sign that one particular facet of its design was a bad idea is pretty laughable. Any new tool takes time to be adopted - and Powershell is a tool for a fairly small niche - CLI users on Windows.
Most data translation projects don't need advanced data structures to get the work done. This common misconception is responsible for a great deal of the software project failures over the last few decades.
I'm just talking about basic data structures here - support for anything beyond strings or text streams. Shell programming has become mired in translation steps. Scripting languages let you avoid all that because the language provides data structures and objects, as well as a reasonable set of baseline data types, which modules written in the language can work with.
Some shells support some data structures and containers, but I think Powershell is the only one right now that can actually pass these between processes...
Now, here's what I'd like to know...
Are you serious here, showing that both shells support useful features, or are you being facetious, showing that both shells are merely acceptable stepping-stones to run Perl code?
I love CLIs but my feeling on most of them is that they're more than a little archaic - the lack of any non-trivial datatypes (and particularly the lack of support for passing structured data or live objects between shell processes) makes it needlessly difficult to get things done - I believe that is one of the major reasons people script with scripting languages these days instead of shells...
So, what, does this refer to people who act like they're going to rip your heart out of your chest, only it all turns out to be a ruse so they can kick you in the balls?
or turn your brother into a mere voice inhabiting a set of japanese armor.......
sadly, most won't get the reference.
See, 'cause FMA is really obscure... :D
Do you propose I play with it in a balloon indoors? If I get arrested for doing something stupid, I'd feel a little better knowing my family won't get soaked in the next rainstorm because I blew the roof off the house.
The above is pretty funny, for certain values of "it"... I mean, you soaked your family? Blew the roof off the house?? Dude...
Umm, McDonald's doesn't serve grass-fed beef, so by definition a large percentage of beef isn't grass-fed.
What?!?!? McDonald's serves beef? This is news to me.
Yeah, apparently some small percentage of each McDonald's hamburger patty is actually comprised of beef.
There is some fantasy among environmentalists that envisions herds of cattle trampling wheat and corn fields.
In my fantasy, after the cattle trample the wheat and corn fields, vegetables would be grown in place of the grains...
"If only we could stop breeding those cows, there'd be food for everyone!" The best beef comes from herds of cows running around on rocky, inhospitable land, eking out an existence eating scrub grass and brambles.
"The best beef" isn't the same thing as "the majority of beef". Most of the beef people are eating isn't "the best beef", and it's not free-range grass-fed beef.
What I object to is the excess of cattle farming. Not cattle farming in general, just the irresponsible practices brought about largely because of our taste for excess.
Farming is a low-profit-margin industry - you don't waste a lot of money buying/hoarding lots of human-edible food to feed your cows.
Well, actually we do waste a lot of money buying and hoarding lots of human-edible food: corn, mostly. The price of the crop is unnaturally reduced by subsidies and the large supply on hand - as a result it's cheap enough to feed to cows to grow beef with. It's not particularly nutritious, though...
... hot!
Can it do that?
Not as such... But it can make the cup, and it could even fill it with something that's almost, but not quite, entirely unlike tea.
The real trick, as I understand it, is to have "tea" and "no tea" at the same time. This goes against common sense, though, so I'm not sure how it could be possible.
But on the other hand - to think of something that would today be a garage kit, only done up as a downloadable design for fabrication... that would be pretty damn cool.
Agreed. But look at the dark side... IP laws are going to apply to this new medium too. Fox or whoever owns the copyrights isn't going to let you sell that Serenity kit even if you created the CAD files as a labor of love.
This is exactly the situation we have today. People who want to sell garage kits of their favorite copyrighted subjects have two options, basically - the first option is to get the kit properly licensed - which actually is practical in some cases. (For instance, an event-only license to sell a kit at Wonder Fest in Japan is pretty reasonable, I hear... There's also the resin Falke that was released a year or two ago, that kit was produced as a garage kit and then officially licensed...)
The second option is to simply "fly under the radar". Keep your operation small, hope you don't get pinched, and cease and desist if so requested. In this category you'll find all sorts of Gundam, Star Wars, Star Trek, etc. And the Serenity...
Of course, part of the reason, I expect, why GKs are allowed to exist is because it's not profitable for a large-scale operation to pursue every last opportunity with the license. Only so many people are going to want a Ferengi pod, or the Klingon cruiser from Star Trek: The Motion Picture (not the Bird of Prey from Trek 3, which tends to be more popular, or the simpler D-7 from the TV series...) Let alone a conversion kit for some obscure variant most people have never heard of... There's just not enough benefit to justify the expense of chasing down all the little GK operations. That, too, may change - since affordable home fabrication would make it trivial to do small production runs affordably, the only concern would be making enough money to cover the costs of developing the pattern... But if that means kit makers can sell a wider variety of designs in the form of fabrication designs, all the better...
3D printing would make that hobby much easier - and obsolete.
How do you figure?
I mean, right now, the model-building hobby is "obsolete" for any number of reasons. Resin Figure kits are obsolete due to high-quality pre-painted polyvinyl, or pre-painted resin products. Injection kits are sold pre-painted, too. Even kits without such gimmicks are generally of such high quality these days that modelers joke that you can "toss in some glue and shake the box" and have a winning model... Some even argue that the whole reliance upon kits has killed modelers' potential to learn "true modeling" - AKA scratch building...
3-D printing does not presently do anything to make modeling obsolete. At some point it will advance far enough that there'll be nothing left to do once the part is printed. But it's a long way from here to there. In the mean time, there will be this new capability, home fabrication, but to really exploit it (produce display pieces from raw fabricated parts) people will have to turn to modeling skills... That's what interests me.
Well, at $50-100 per part according to TFS, a 200-part kit is going to set you back a pretty penny.
Did you not get the part where I'm talking about the future potential of 3-D printing? Do you really think it's always going to be as expensive as it is now?
IMO, 3D printing solves one problem (generating copies of a design) but not the other (creating the design in the first place).
I've done a little bit of computer modeling and a fair bit of scratch-building - certainly there are things that are perfectly simple to do by hand, not worth complicating the process by introducing a computer-design phase... And there's inherent limitations in current display and input technologies that make it difficult to model on the computer, even with the right tools...
But on the other hand, I've basically finished my computer-modeled Zaku, but the process of making the corresponding physical parts has been very slow. Maybe this says more about my lack of skill at scratch building than it does about the relative ease of computer modeling, I don't know... But either way, once a model design is on the computer, cheap fabrication would mean cheap production and flexible distribution... A great thing for people who want to have kits, I bet - probably not so great for people who want to sell them. :D
I am aware that 3-D printed parts are already a present-day reality - what I'm looking forward to is a point when it's as cheap and accessible as papercraft is today.