This doesn't look like it'll be replacing.NET or VB anytime soon. It looks like an IDE for JSP-based sites, not something that will replace VB as a quick-n-dirty IDE for end-user apps nor will it be anything like.NET, which goes far beyond one language and one way of doing things, as Java+Sun provide.
But then again, it's not out, I've not used it, so I can't say that for sure. It looks like an equivalent to an ASP-builder, which can use VBScript.
Java the language could not simply out-VB VB. The language itself is too complicated in ways that will not be solved by a GUI builder. Java could be used as the platform for a language and IDE akin to VB, but taking Java the language and adding an IDE will not make many VB coders productive without doing all the learning of Java that any other Java coder has gone through.
I can't say I've seen it that bad, but for the providers where I am, bluetooth is only found on the upper 25% of the phones they sell. The more expensive and full featured ones.
I don't have a cell phone and have just about no desire to have people talking at me whenever I'm out. I do not like the regular phone unless there is no alternative.
But, the prospect of using the cellular data network to get access on my PDA does interest me. I understand that the phones with bluetooth allow you on your laptop or PDA (or desktop, I suppose) with a bluetooth chip to get net access through the cellular setup via bluetooth. That interests me, especially considering there aren't any cards for my PDA that would provide the same service, although that would be more convenient.
A friend of mine just got a Hiptop Sidekick from tmobile- $30/month and he gets unlimited data, and doesn't have to pay for talkie minutes. For $30 I just might do it- but when I looked for a bluetooth phone for this setup, it looked like I had to buy a $200-300 phone for it. Half of those were semi-PDAs in their own right, and I can say that I certainly am not interested in carrying around two PDA-ish devices.
Why can't someone make a cheap and small (around the size of two stacked matchboxes) cellular box for such a purpose? No LCD, no speaker no mic- just bluetooth, SIM, and the correct GRPS/cell hardware. I could keep it in my pocket or in my backpack, out of the way. It would be better than gettign a PDA with the cellular stuff built in, at least until service starts to be more convenient.
That is, I have a PDA that is quite one of the kid- a Zaurus C760. If it was supported only by one company, and I wanted to upgrade, I'd have to ditch ti and get somethign else, something very possibly inferior. Until then, a little bluebox would be slick.
Anyone know how the media for this thing will be managed? More precisely, how the rights to use the media.
With the UMD discs holding 1.8 GB and a CPU(s) to handle it easily, it seems like the PSP could make an awesome portable MP3 player. I'd love to be able to burn my whole collection on a few UMD discs, and have one or two with me when I want to listen to some tunes. I use my PDA these days, but with newer PDAs no longer having PCMCIA slots, it'll be a while until I can have a couple GB or more on a card. I used to have a 2 GB PCMCIA HD (and could've had up to 30!) in my PDA, which was sweet.
From the Register article: UMD comes with DVD-style region coding and copy-protection mechanism based on the Advanced Encryption System (AES). Each disc has a unique ID number too.
It don't sound too hot, at least for schmuck consumers like us.
Yes, I'm somewhat aware of the pains of porting to PalmOS. I code in Squeak Smalltalk, and a lot of Squeak users would like to have it on their PDAs. While a port was done to WinCE, Linux for the PDA and even EPOC32 with relative ease, nothing has surfaced for the PalmOS.
I'm hoping a lot of these issues will be solved in POS 6 so that apps like Squeak- and MAME- can finally be ported. These inadequacies are also why I don't use a Palm device- I demand too much from my PDAs.
No, I haven't found any perfect device yet, although the Newton MP2100 is by far the device which has come closest. My second favorite PDA has been the Jornada 720 Handheld PC, though I would prefer a device that could be converted between "mini-laptop" and "palm" mode, like the Zaurus but with better software. I just got a Sigmarion III, and it's a sweet device. Although, it can't convert between the handheld pc
I never said the Zodiac is perfect. I don't own one, and certainly couldn't make that kind of claim. Things are bound to improve, compatability problems be taken care of, etc etc. Especially with POS6 things should be getting better.
I assume you have them all for testing and such, but if you ever have an old PalmOS device you don't need anymore, drop me a line... I'm looking for one for stealing UI ideas from. Not a copy or anything, but figuring out what would work and what wouldn't. We have an old PalmPro, but it rarely works.
Meh, it was just an example. I don't own a Zodiac or any Palm device at this point (except a barely-working Palm Pro). Lemmings may be a poor example for other reasons- you did a decent job at making it work well on a touch screen, unlike some games. Snood is a game that works better with a mouse or d-pad, IMHO.
I wouldn't be surprised if Lemmings worked on the new ARM-based b/w Zire, but it doesn't mean there aren't better PDAs out there.
BTW- thanks for all the work you did on the Helio. I bought one of those puppies when they first came out with the intention of running Linux. And did for a while using my own app written in Squeak, as none of the Linux GUIs for it were useful at all.
But, until I finished that, I used VTOS, along with some of your apps. Especially great was the GB emu for the Helio, although it was only worth playing a few games because the controls sucked- like they do on most PDAs.
Touchscreens may make an OK substitute for mouse control, but it makes a horrible substitute for a good d-pad and well-placed A/B buttons. The Zodiac has a button setup prefect for gaming, most PDAs, PocketPC or Palm, do not.
There are all of these emulators for the PalmOS as well. One exception is a GBA emulator- it's slow in coming. I'm not sure what the status of it is on WinCE though either.
But if I were going to spend $300-400 on a PalmOS PDA, and even did just a smidge of gaming I would go for the Tapwave in a heartbeat. A nice 480x320 screen, dual SD (incl SDIO), nice gaming buttons, bluetooth, and the most memory any PalmOS unit can have. No, it doesn't have a camera or a shitty thumboard, but I don't need either of those things and didn't use them even if my PDA had them.
I could see not getting a Tapwave if you were set on a PocketPC, or wanted to spend $200 rather than $300-400. A Dell Axim X3/5 or Tungsten E both can be had for $200 and can be used for emulators of all kinds- MAME, NES, SNES, etc- as well as rad games like Snood for the native platform. Hell, even the new ARM-based b/w Zire could be used for playing games with these emulators for a mere $99.
But then again, I won't touch PalmOS until it can do what I'm used to doing on platforms like the Zaurus or WinCE. But maybe by POS 6 a Palm device will be ready for me.
The Tapwave has a chance, where the GP32, etc did not. The Zodiac- at $300 and $400 for the 32 MB and 128 MB models respectively- make sense to buy as PDAs. The price is right for similar items in their class, they've some features that most PalmOS PDAs don't have and a few that no other POS PDA has.
It's all about how Tapwave goes about marketing it. If they market is just as gaming device, mostly ignoring the fact that it's ultimately a PDA, a pocket computer it will die. After all, why spend 300-400$ on something like that when you could get a GBA for $80?
But, if they market it as a PDA that has some very convenient perks- like having real gaming controls, dual SD slots, a big screen, a nice "GPU-" then it could succeed, although within a niche. If I were in the market for a PalmOS PDA, there is a very good chance that I would buy the Zodiac. And if I bought a Zodiac, there's only a very small chance I'd buy any Zodiac-specific games- maybe one or two if something really caught my eye, but I'd mostly use it like I use all PDAs I've owned- as very small computer. Coding, SSH/telnet/VNC, writing papers, web, email, etc.
Out of what I do, I spend the least amount on playing games. But part of the reason that is the case is that just about all PDAs up until the Zodiac has shitty controls. Some have a decent d-pad and button placement for gaming, but then you are stuck with the problem of not being able to register more than one button press at a time, among other issues. But, I would play Snood (maybe even register it again!) SimCity, Lemmings and some other games that work on any recent POS device.
The good gaming button setup is a perk for someone like me, a conveinence but not a reason to buy. It may be able to do a little learning if there was another PDA with comparable hardware for the same price, but only if the prices and hardware were almost the same.
That fact that most people can't figure this out for themselves means that Tapwave isn't doing the marketing right, or that most people haven't owned a PDA. I think both are at fault, especially the latter. This thing shouldn't be compared to the GBA so much as it should to other PDAs in its class.
Yeah, it's a shame xtunes is gone. JuK doesn't look like much of an iTunes clone- where is the browse feature ala iTunes? I don't mean the iTMS, but the reason I use iTunes on my Mac- being able to use a paned-browser to navigate to the CD I want to listen to, rather than having to maintain play lists- which is why I don't use XMMS or an older Winamp.
Yeah, those are two good packages. There are more as well. Maxima is a free version and derivative of the DOE's Macsyma. I used to use JACAL on WinCE under PocketScheme, but it works in any standard scheme... Have fun with them!
Also, since I have a pretty capable PDA with network capability, sometimes I've SSH'd to mhe school Solaris box and just run Mathematica there. Displaying via VNC or remote X11 to a WinCE or Linux PDA is a bit slow and putzy, but the command line version works great.
Yeah, Octave doesn't cut it by itself. I've been trying to get it to do so, by finding a symbolic toolkit like you do in Matlab.
In any case, there are other tools that work as an analog to Mathematica where octave is one to matlab- I use GNU Maxima now, though I used to use JACAL in Pocket Scheme. Both have no problems doing derivations.
I don't know what kind of "windows calculator applicatons" you've been using, but what I use- on Linux, Windows, OS X, as well as on my PDAs (Linux and WinCE) I run a "calculator app" that beats the pants off of a TI-89, or even a 92.
What is that app? GNU Octave! And on the Windows machine, Matlab and Mathematica. Totally creams a TI calc.
That said, a TI calc is still pretty useful. Before I got the hang of using GNU Octave on my Zaurus, I installed a TI-85 emulator which is decent, though sometimes annoying to use, as it duplicates the real calculator down to every detail.
The REX model my roomate had a touch screen and input capabilities. It was added at least added for the newest model, may have been there longer. I did a quick look at the FAQ at rex6000.org, and there are some questions about how typing on the onscreen kb gets slow after 38 characters. So I know I'm not imaginging it, although I used it a bunch playing around with it and such.
A while back, I hacked together a read only PDA software suite. See, I use my PDA as a computer, not just as a very overpriced day book. My PDA at the time was a Jornada 720, which was my primary computer. My girlfriend didn't like how whenever I had a minute of downtime anywhere I was, I'd whip out the J720 and start coding or reading an ebook... Just efficient time usage to me.
So, to get myself do not do that, but still have all of my information available, I wrote an app in Squeak Smalltalk that was naught more than a PIM data browser. While I could've entered text, the actual app had no input capabilities. The hardware platform was the V-tech Helio and the OS was Linux. As a matter of fact, the Helio was the first PDA you could buy that could run a real Linux kernel. So, I just had this puppy get a new textfile of all of the PIMish data on my other PDA via Xmodem from the desktop and have it all there without such a temptation to read or write code.:P
No, you could input data on it. Perhaps the oldest model you couldn't, I wouldn't know. But the model my roomate had, one of the newer ones, had a ~ 240x160 screen (?) and a touch screen. Didn't have character recognition or anything, but it did have an on screen keyboard used for entering new appointments and such.
My roomate didn't have a windows box to sync this thing with- anything on it he entered himself. With the exception of a couple ebooks I put on using my own PDA, a Jornada 720 with a PCMCIA slot. Kind of funny, syncing a PDA with a PDA, but yeah.
You certainly shouldn't say that "16-bit" color equates to 65536 colors anymore. Lots of those are greys. Taking out all greys, black and white, that would leaving 65278 colors or 15.99431 bit color. Yeah.
Except the Nokia 7700 doesn't have a 640x480 screen but a 640x320 one. Not a huge deal- I was able to do 80x25 (and wider if I wanted) SSH/telneting on a 640x240 Jornada 720.
It shouldn't be long until there is something with all of that. There are many devices with all but one of those things. There are plenty of PDAs with a MP3 player, camera, thumboard, and bluetooth. That setup, along with a bluetooth phone and you've got the WAN net access. Yeah, you'd have to carry around a phone too, but for the time being a real phone seems to be the better choice.
What I wish I could get is a tiny cellular module that is bluetooth enabled to which I could connect from my PDA for net access. I don't like cell phones or hell, the phone in general. I don't like to talk to people on the blabber box. But, I still would like an inexpensive little box that would give my chosen computer, be it laptop or PDA, network access. I don't want to have to worry about getting a new phone if I want to switch providers, or if I want to get a newer, faster or otherwise better PDA I don't want to have to worry about the status of my contract, etc etc. There are a number of reasons to keep the phone business on a card or happy little box, especially for a person like me who uses his PDA as my main computer and upgrades relatively often.
P.S. Why the hell do you keep saying "Thou?" I thinkest thou should start sayething tho or though methinks it dear Sire.
As it stands, this looks to be roughly the size of a REX with touch-screen data entry added.
The later REX models did have touch-screen data entry. My roomate had a REX up until recently when his dumb ass set on it at some angle that broke it. Anywho, he could enter text- a new appointment, note, todo, whatever- using an on-screen keyboard, and tap various widgets using the touchscreen.
It was a really nice little device, not capable whatsoever compared to most of the PDAs you could buy for the same price (he spent ~$200 around 1.5-2 years ago), but really small and enough for what he wanted.
IIRC, the REX had very little RAM and a very slow (1-3 MHz Z80) CPU, but it got great batter life on its two lil watch batteries for normal use. He tried using it as an ebook reader but found that having it on constanltly killed batteries.
For one, the middle man enables you -the shell user- to just type a command, perhaps type some more input, and read the output.
Problem wouldn't be an issue like it would in C++. In.NET, every object inherits from the System.Object class, so there's no reason your object wouldn't be accepted.
Having the MSH- or any other shell, by MS or someone else- return an object doesn't hinder the ability for a user to read the output. See, returning an object gives the end-user using the shell as well as developers a lot more power.
I can't claim to know a lot about the CLI and the.NET object model outside of what it promises, I've not done a bunch of work with it in the real world. A language I have done a lot of work in though, is Smalltalk. Smalltalk's objects have a method- printOn:- which will print some representation of the object on a stream; the counterpart asString renders it as a string. Now, if you were using MSH, and typed a command directly at the shell, the command would be rendered into a human readable form. It's not like if you typed "ls" you would just get something like "#" and nothing else.
But, in the case you did a pipe, you wouldn't have to get primitive and parse that text. Why write code that renders output into text you just have to go an un-render?
See, one of the benefits of OOP is polymorphism. There isn't reason that every.NET object would respond to a method like asString. Naturally, not all objects should be used at the command line neccesarily, but there certainly are times when you need to go beyond what the designer expected.
Secondly, the middle man enables you to easily chain (pipe the i/o of) various tools/commands in ways the authors of these tools might not have expected.
Certainly, something like this may be a pain in C++, but not in.NET (or other languages like Smalltalk, Ruby, Python). Unless you're using a program that was intentionally poorly designed, passing what is returned via a pipe or redirection won't be a problem. That's a relatively silly argument against such a system. There would be no need to write a script that casts/converts what was returned by one method/program to something another could understand, unless you had actual processing to do, which sometimes you will... But that is sometimes the case no matter if you're piping a string or a real object. In fact, with something like the setup in MSH, you'll have to do less fiddling to get this.
By creating an interactive layer over.NET, what MS has really done is bringing an interactive scripting language like basic or python into the world.
Yes, it is that- and more. It's a step beyond that. Python has an interactive prompt, but typing commands like "ls" on a Linux box don't do anything other than spit out an error. (Unless you have a variable called ls, of course) Something very close to what MSH is is the Perl shell, psh. MSH takes what psh does a little further, but the idea is very much the same. Much to my annoyance, if I pipe an "ls" in psh, I still have to do parsing and such. I'd much rather me able to do-
ls | foreach $file (@files) { doSomething($file); }
Rather than throwing a bunch of parsing in there. In the case of "ls" the example we're using wouldn't be that much worse, but you should be able to understand in principle what I'm saying.
This "shell" will be perfect for scripting, but be rather not so good for interactive use if MS doesn't provide a big, cleverly written middle man library.
A big, cleverly written middle man library isn't neccesary. Yes, it would be for C++ and probably Java, but not for.NET. No, I'm not a big fan of MS- if I use anything like this, it will be a part of Mono and not something by Microsoft's. But having read a fair amount of stuff about Mono and.NET, I have to say that it looks like they did- and are doing- a lot of things a lot better than we've been made to get used to in the past with Unix and Windows, C, C++ and Java.
By the way, "Bob" exiled Eris to the bog of eternal stench a long time ago. The X-ists have lost- forever!
My bad- F# is based on ML, not Haskell. I had thought it was based on Haskell, and assumed (note I said "presumably") that he was a part of that project, considering his knowledge in the area.
I had confused this with Mondrian and Haskell.NET, other functional.NET languages that are Haskell-based, though not being done by Jones or anyone else at MSR.
Umm, he didn't mean to say it was. Re-read the post. What he meant was that bash/sh syntax is akin to make- it's ripe for replacing, but it's too entrenched just to toss everyone something that's just technically better.
why bother re-inventing the wheel. if you're doing something simple that coul dbe handled with pipes and redirects and simple unix commands (wc, cmp, diff, cksum, etc) and it's repetitive, just write a bash script.
It's not a matter of reinventing the wheel so much as improving it. Why shouldn't you just keep on driving an old electric scooter when you could have a new Honda Hybrid Civic? More powerful without unneccesary overhead, preserving functionality while making it simpler and more straight forward.
When doing Unix pipes, you're stuck parsing text and trying to interpret what one program output and using that. There is no consistency or standard interface. With a setup like MSH (or Perl Shell psh!), your commands can return data structures- objects, arrays, etc- which you can use without wasting your time or computational power parsing and processing.
if you're talking about full-featured programming, regexps and everything then why would you want to do it in a shell script.
I don't know if you've ever done any shell scripting, but regexps are very much a part of what you have to deal with. Things aren't just a matter of piping, with one program knowing what to spit out so that the other program knows. On Unix, regexps are pretty much how you deal with that.
Why should I have to write an ugly C or C++ app to do something relatively simple and straightforward just because my shell language is inadequate? That adds up to a ton of wasted time. There is no reason a shell shouldn't provide the features of a real programming language- as long as it doesn't get in the way of using it like a shell. (E.g. Scsh does, IMHO)
Re:Much of this could be done in linux...
on
Microsoft's new CLI
·
· Score: 2, Insightful
psh never really seemed to take off but it let you basically enter a perl debugging session but execute shell commands also. This would basically trump anything msh could muster and also provide the entire universe of CPAN to the shell.
First- on OS X and Linux, I use psh. I love having a real language as my shell, no need to write little glueish C programs or look up really (more than perl sometimes!) obscure bash syntax. As far as Unix shells go, it's definately top shelf.
But I don't think it could trump MSH- unless we were talking about Perl.NET running psh on Windows or under other OSes using Mono. MSH has some serious strengths- like having access to everything going on in the computer, all of the.NET API- that psh as I use it now does not, putting it in the position to *be* trumped by MSH rather than the other way around. Hell, MSH, with Perl.NET installed, could just as easily use all of that CPAN stuff as you could in vanilla psh.
But, put psh on top of Perl.NET and we've got a really capable setup. Sign me up! Perhaps psh+mono could be the OSS/FS community's answer to MSH on.NET.
And, presumably by that prime developer you mention, MS Research has a Haskell-like language for.NET. All the convenience of.NET and its API with none of tha pain in using a sucky language like C++ or C#.
Re:Nothing new except overkill
on
Microsoft's new CLI
·
· Score: 2, Informative
And as for returning search results as.NET objects? This seems rather like using a baseball bat to swat a fly...
Certainly doesn't seem that way to me. It's not like a.NET object is an 800 lb gorilla. It's jut an object. And being an object, rather than a file or text in a certain format, binary or text, it's ready to be used in your script or application, without having to read in, parse, or otherwise make the output or file actually useful.
When writing shell scripts on Linux or Mac OS X, there have been a million times where I've wished the output of a redirected/piped Unix command was available to me in an immediately useful way- rather than to have to write a bunch of regexes or parsing function. It's a pain in the ass. I'd love for ps to return a dictionary (hash, map) of my processes, I could spend my time writing the code that actually did something, rather than parsing the text.
A,NET object is just an object. Really not all that much more overhead compared to using printfs or spitting it out to a file and then writing your own code to process that text. Why not cut out the middle man?
Except, as unfortunate as it may be, the shells we use in Linux today for the most part are 80s (or older) technology, but then again, so is MS's CMD.exe. But this new MSH setup isn't the same old kruft that's kept around because so many things use it- it's a new shellwith total integration. The ability to call into any library on the system. I certainly couldn't do that with bash.
Slashdot Mirror
This doesn't look like it'll be replacing .NET or VB anytime soon. It looks like an IDE for JSP-based sites, not something that will replace VB as a quick-n-dirty IDE for end-user apps nor will it be anything like .NET, which goes far beyond one language and one way of doing things, as Java+Sun provide.
But then again, it's not out, I've not used it, so I can't say that for sure. It looks like an equivalent to an ASP-builder, which can use VBScript.
Java the language could not simply out-VB VB. The language itself is too complicated in ways that will not be solved by a GUI builder. Java could be used as the platform for a language and IDE akin to VB, but taking Java the language and adding an IDE will not make many VB coders productive without doing all the learning of Java that any other Java coder has gone through.
I can't say I've seen it that bad, but for the providers where I am, bluetooth is only found on the upper 25% of the phones they sell. The more expensive and full featured ones.
I don't have a cell phone and have just about no desire to have people talking at me whenever I'm out. I do not like the regular phone unless there is no alternative.
But, the prospect of using the cellular data network to get access on my PDA does interest me. I understand that the phones with bluetooth allow you on your laptop or PDA (or desktop, I suppose) with a bluetooth chip to get net access through the cellular setup via bluetooth. That interests me, especially considering there aren't any cards for my PDA that would provide the same service, although that would be more convenient.
A friend of mine just got a Hiptop Sidekick from tmobile- $30/month and he gets unlimited data, and doesn't have to pay for talkie minutes. For $30 I just might do it- but when I looked for a bluetooth phone for this setup, it looked like I had to buy a $200-300 phone for it. Half of those were semi-PDAs in their own right, and I can say that I certainly am not interested in carrying around two PDA-ish devices.
Why can't someone make a cheap and small (around the size of two stacked matchboxes) cellular box for such a purpose? No LCD, no speaker no mic- just bluetooth, SIM, and the correct GRPS/cell hardware. I could keep it in my pocket or in my backpack, out of the way. It would be better than gettign a PDA with the cellular stuff built in, at least until service starts to be more convenient.
That is, I have a PDA that is quite one of the kid- a Zaurus C760. If it was supported only by one company, and I wanted to upgrade, I'd have to ditch ti and get somethign else, something very possibly inferior. Until then, a little bluebox would be slick.
Anyone know how the media for this thing will be managed? More precisely, how the rights to use the media.
With the UMD discs holding 1.8 GB and a CPU(s) to handle it easily, it seems like the PSP could make an awesome portable MP3 player. I'd love to be able to burn my whole collection on a few UMD discs, and have one or two with me when I want to listen to some tunes. I use my PDA these days, but with newer PDAs no longer having PCMCIA slots, it'll be a while until I can have a couple GB or more on a card. I used to have a 2 GB PCMCIA HD (and could've had up to 30!) in my PDA, which was sweet.
From the Register article:
UMD comes with DVD-style region coding and copy-protection mechanism based on the Advanced Encryption System (AES). Each disc has a unique ID number too.
It don't sound too hot, at least for schmuck consumers like us.
Will this situation improve in PalmOS 6?
Yes, I'm somewhat aware of the pains of porting to PalmOS. I code in Squeak Smalltalk, and a lot of Squeak users would like to have it on their PDAs. While a port was done to WinCE, Linux for the PDA and even EPOC32 with relative ease, nothing has surfaced for the PalmOS.
I'm hoping a lot of these issues will be solved in POS 6 so that apps like Squeak- and MAME- can finally be ported. These inadequacies are also why I don't use a Palm device- I demand too much from my PDAs.
No, I haven't found any perfect device yet, although the Newton MP2100 is by far the device which has come closest. My second favorite PDA has been the Jornada 720 Handheld PC, though I would prefer a device that could be converted between "mini-laptop" and "palm" mode, like the Zaurus but with better software. I just got a Sigmarion III, and it's a sweet device. Although, it can't convert between the handheld pc
I never said the Zodiac is perfect. I don't own one, and certainly couldn't make that kind of claim. Things are bound to improve, compatability problems be taken care of, etc etc. Especially with POS6 things should be getting better.
I assume you have them all for testing and such, but if you ever have an old PalmOS device you don't need anymore, drop me a line... I'm looking for one for stealing UI ideas from. Not a copy or anything, but figuring out what would work and what wouldn't. We have an old PalmPro, but it rarely works.
Meh, it was just an example. I don't own a Zodiac or any Palm device at this point (except a barely-working Palm Pro). Lemmings may be a poor example for other reasons- you did a decent job at making it work well on a touch screen, unlike some games. Snood is a game that works better with a mouse or d-pad, IMHO.
I wouldn't be surprised if Lemmings worked on the new ARM-based b/w Zire, but it doesn't mean there aren't better PDAs out there.
BTW- thanks for all the work you did on the Helio. I bought one of those puppies when they first came out with the intention of running Linux. And did for a while using my own app written in Squeak, as none of the Linux GUIs for it were useful at all.
But, until I finished that, I used VTOS, along with some of your apps. Especially great was the GB emu for the Helio, although it was only worth playing a few games because the controls sucked- like they do on most PDAs.
Touchscreens may make an OK substitute for mouse control, but it makes a horrible substitute for a good d-pad and well-placed A/B buttons. The Zodiac has a button setup prefect for gaming, most PDAs, PocketPC or Palm, do not.
There are all of these emulators for the PalmOS as well. One exception is a GBA emulator- it's slow in coming. I'm not sure what the status of it is on WinCE though either.
But if I were going to spend $300-400 on a PalmOS PDA, and even did just a smidge of gaming I would go for the Tapwave in a heartbeat. A nice 480x320 screen, dual SD (incl SDIO), nice gaming buttons, bluetooth, and the most memory any PalmOS unit can have. No, it doesn't have a camera or a shitty thumboard, but I don't need either of those things and didn't use them even if my PDA had them.
I could see not getting a Tapwave if you were set on a PocketPC, or wanted to spend $200 rather than $300-400. A Dell Axim X3/5 or Tungsten E both can be had for $200 and can be used for emulators of all kinds- MAME, NES, SNES, etc- as well as rad games like Snood for the native platform. Hell, even the new ARM-based b/w Zire could be used for playing games with these emulators for a mere $99.
But then again, I won't touch PalmOS until it can do what I'm used to doing on platforms like the Zaurus or WinCE. But maybe by POS 6 a Palm device will be ready for me.
The Tapwave has a chance, where the GP32, etc did not. The Zodiac- at $300 and $400 for the 32 MB and 128 MB models respectively- make sense to buy as PDAs. The price is right for similar items in their class, they've some features that most PalmOS PDAs don't have and a few that no other POS PDA has.
It's all about how Tapwave goes about marketing it. If they market is just as gaming device, mostly ignoring the fact that it's ultimately a PDA, a pocket computer it will die. After all, why spend 300-400$ on something like that when you could get a GBA for $80?
But, if they market it as a PDA that has some very convenient perks- like having real gaming controls, dual SD slots, a big screen, a nice "GPU-" then it could succeed, although within a niche. If I were in the market for a PalmOS PDA, there is a very good chance that I would buy the Zodiac. And if I bought a Zodiac, there's only a very small chance I'd buy any Zodiac-specific games- maybe one or two if something really caught my eye, but I'd mostly use it like I use all PDAs I've owned- as very small computer. Coding, SSH/telnet/VNC, writing papers, web, email, etc.
Out of what I do, I spend the least amount on playing games. But part of the reason that is the case is that just about all PDAs up until the Zodiac has shitty controls. Some have a decent d-pad and button placement for gaming, but then you are stuck with the problem of not being able to register more than one button press at a time, among other issues. But, I would play Snood (maybe even register it again!) SimCity, Lemmings and some other games that work on any recent POS device.
The good gaming button setup is a perk for someone like me, a conveinence but not a reason to buy. It may be able to do a little learning if there was another PDA with comparable hardware for the same price, but only if the prices and hardware were almost the same.
That fact that most people can't figure this out for themselves means that Tapwave isn't doing the marketing right, or that most people haven't owned a PDA. I think both are at fault, especially the latter. This thing shouldn't be compared to the GBA so much as it should to other PDAs in its class.
In otherwords- most KDE apps look like shit, so JuK should too!
I suppose I follow that- consistency over all I say. No, iTunes uses brushed metal, but manages to be pretty consistent with the other "iApps."
Yeah, it's a shame xtunes is gone. JuK doesn't look like much of an iTunes clone- where is the browse feature ala iTunes? I don't mean the iTMS, but the reason I use iTunes on my Mac- being able to use a paned-browser to navigate to the CD I want to listen to, rather than having to maintain play lists- which is why I don't use XMMS or an older Winamp.
Yeah, those are two good packages. There are more as well. Maxima is a free version and derivative of the DOE's Macsyma. I used to use JACAL on WinCE under PocketScheme, but it works in any standard scheme... Have fun with them!
Also, since I have a pretty capable PDA with network capability, sometimes I've SSH'd to mhe school Solaris box and just run Mathematica there. Displaying via VNC or remote X11 to a WinCE or Linux PDA is a bit slow and putzy, but the command line version works great.
Yeah, Octave doesn't cut it by itself. I've been trying to get it to do so, by finding a symbolic toolkit like you do in Matlab.
In any case, there are other tools that work as an analog to Mathematica where octave is one to matlab- I use GNU Maxima now, though I used to use JACAL in Pocket Scheme. Both have no problems doing derivations.
I don't know what kind of "windows calculator applicatons" you've been using, but what I use- on Linux, Windows, OS X, as well as on my PDAs (Linux and WinCE) I run a "calculator app" that beats the pants off of a TI-89, or even a 92.
What is that app? GNU Octave! And on the Windows machine, Matlab and Mathematica. Totally creams a TI calc.
That said, a TI calc is still pretty useful. Before I got the hang of using GNU Octave on my Zaurus, I installed a TI-85 emulator which is decent, though sometimes annoying to use, as it duplicates the real calculator down to every detail.
And I'm on my Sigmarion III PDA, with even a better screen than that on my Zaurus SL-C760- 800x480. :)
I'd rather have a 320x240 greyscale screen than the abomonation of shit lord that was on my Zaurus SL-5500...
The REX model my roomate had a touch screen and input capabilities. It was added at least added for the newest model, may have been there longer. I did a quick look at the FAQ at rex6000.org, and there are some questions about how typing on the onscreen kb gets slow after 38 characters. So I know I'm not imaginging it, although I used it a bunch playing around with it and such.
:P
A while back, I hacked together a read only PDA software suite. See, I use my PDA as a computer, not just as a very overpriced day book. My PDA at the time was a Jornada 720, which was my primary computer. My girlfriend didn't like how whenever I had a minute of downtime anywhere I was, I'd whip out the J720 and start coding or reading an ebook... Just efficient time usage to me.
So, to get myself do not do that, but still have all of my information available, I wrote an app in Squeak Smalltalk that was naught more than a PIM data browser. While I could've entered text, the actual app had no input capabilities. The hardware platform was the V-tech Helio and the OS was Linux. As a matter of fact, the Helio was the first PDA you could buy that could run a real Linux kernel. So, I just had this puppy get a new textfile of all of the PIMish data on my other PDA via Xmodem from the desktop and have it all there without such a temptation to read or write code.
No, you could input data on it. Perhaps the oldest model you couldn't, I wouldn't know. But the model my roomate had, one of the newer ones, had a ~ 240x160 screen (?) and a touch screen. Didn't have character recognition or anything, but it did have an on screen keyboard used for entering new appointments and such.
My roomate didn't have a windows box to sync this thing with- anything on it he entered himself. With the exception of a couple ebooks I put on using my own PDA, a Jornada 720 with a PCMCIA slot. Kind of funny, syncing a PDA with a PDA, but yeah.
You certainly shouldn't say that "16-bit" color equates to 65536 colors anymore. Lots of those are greys. Taking out all greys, black and white, that would leaving 65278 colors or 15.99431 bit color. Yeah.
Except the Nokia 7700 doesn't have a 640x480 screen but a 640x320 one. Not a huge deal- I was able to do 80x25 (and wider if I wanted) SSH/telneting on a 640x240 Jornada 720.
It shouldn't be long until there is something with all of that. There are many devices with all but one of those things. There are plenty of PDAs with a MP3 player, camera, thumboard, and bluetooth. That setup, along with a bluetooth phone and you've got the WAN net access. Yeah, you'd have to carry around a phone too, but for the time being a real phone seems to be the better choice.
What I wish I could get is a tiny cellular module that is bluetooth enabled to which I could connect from my PDA for net access. I don't like cell phones or hell, the phone in general. I don't like to talk to people on the blabber box. But, I still would like an inexpensive little box that would give my chosen computer, be it laptop or PDA, network access. I don't want to have to worry about getting a new phone if I want to switch providers, or if I want to get a newer, faster or otherwise better PDA I don't want to have to worry about the status of my contract, etc etc. There are a number of reasons to keep the phone business on a card or happy little box, especially for a person like me who uses his PDA as my main computer and upgrades relatively often.
P.S. Why the hell do you keep saying "Thou?" I thinkest thou should start sayething tho or though methinks it dear Sire.
As it stands, this looks to be roughly the size of a REX with touch-screen data entry added.
The later REX models did have touch-screen data entry. My roomate had a REX up until recently when his dumb ass set on it at some angle that broke it. Anywho, he could enter text- a new appointment, note, todo, whatever- using an on-screen keyboard, and tap various widgets using the touchscreen.
It was a really nice little device, not capable whatsoever compared to most of the PDAs you could buy for the same price (he spent ~$200 around 1.5-2 years ago), but really small and enough for what he wanted.
IIRC, the REX had very little RAM and a very slow (1-3 MHz Z80) CPU, but it got great batter life on its two lil watch batteries for normal use. He tried using it as an ebook reader but found that having it on constanltly killed batteries.
For one, the middle man enables you -the shell user- to just type a command, perhaps type some more input, and read the output.
.NET, every object inherits from the System.Object class, so there's no reason your object wouldn't be accepted.
.NET object model outside of what it promises, I've not done a bunch of work with it in the real world. A language I have done a lot of work in though, is Smalltalk. Smalltalk's objects have a method- printOn:- which will print some representation of the object on a stream; the counterpart asString renders it as a string. Now, if you were using MSH, and typed a command directly at the shell, the command would be rendered into a human readable form. It's not like if you typed "ls" you would just get something like "#" and nothing else.
.NET object would respond to a method like asString. Naturally, not all objects should be used at the command line neccesarily, but there certainly are times when you need to go beyond what the designer expected.
.NET (or other languages like Smalltalk, Ruby, Python). Unless you're using a program that was intentionally poorly designed, passing what is returned via a pipe or redirection won't be a problem. That's a relatively silly argument against such a system. There would be no need to write a script that casts/converts what was returned by one method/program to something another could understand, unless you had actual processing to do, which sometimes you will... But that is sometimes the case no matter if you're piping a string or a real object. In fact, with something like the setup in MSH, you'll have to do less fiddling to get this.
.NET, what MS has really done is bringing an interactive scripting language like basic or python into the world.
.NET. No, I'm not a big fan of MS- if I use anything like this, it will be a part of Mono and not something by Microsoft's. But having read a fair amount of stuff about Mono and .NET, I have to say that it looks like they did- and are doing- a lot of things a lot better than we've been made to get used to in the past with Unix and Windows, C, C++ and Java.
Problem wouldn't be an issue like it would in C++. In
Having the MSH- or any other shell, by MS or someone else- return an object doesn't hinder the ability for a user to read the output. See, returning an object gives the end-user using the shell as well as developers a lot more power.
I can't claim to know a lot about the CLI and the
But, in the case you did a pipe, you wouldn't have to get primitive and parse that text. Why write code that renders output into text you just have to go an un-render?
See, one of the benefits of OOP is polymorphism. There isn't reason that every
Secondly, the middle man enables you to easily chain (pipe the i/o of) various tools/commands in ways the authors of these tools might not have expected.
Certainly, something like this may be a pain in C++, but not in
By creating an interactive layer over
Yes, it is that- and more. It's a step beyond that. Python has an interactive prompt, but typing commands like "ls" on a Linux box don't do anything other than spit out an error. (Unless you have a variable called ls, of course) Something very close to what MSH is is the Perl shell, psh. MSH takes what psh does a little further, but the idea is very much the same. Much to my annoyance, if I pipe an "ls" in psh, I still have to do parsing and such. I'd much rather me able to do-
ls | foreach $file (@files) { doSomething($file); }
Rather than throwing a bunch of parsing in there. In the case of "ls" the example we're using wouldn't be that much worse, but you should be able to understand in principle what I'm saying.
This "shell" will be perfect for scripting, but be rather not so good for interactive use if MS doesn't provide a big, cleverly written middle man library.
A big, cleverly written middle man library isn't neccesary. Yes, it would be for C++ and probably Java, but not for
By the way, "Bob" exiled Eris to the bog of eternal stench a long time ago. The X-ists have lost- forever!
My bad- F# is based on ML, not Haskell. I had thought it was based on Haskell, and assumed (note I said "presumably") that he was a part of that project, considering his knowledge in the area.
.NET languages that are Haskell-based, though not being done by Jones or anyone else at MSR.
I had confused this with Mondrian and Haskell.NET, other functional
bash/sh syntax is nothing like a makefile
Umm, he didn't mean to say it was. Re-read the post. What he meant was that bash/sh syntax is akin to make- it's ripe for replacing, but it's too entrenched just to toss everyone something that's just technically better.
why bother re-inventing the wheel. if you're doing something simple that coul dbe handled with pipes and redirects and simple unix commands (wc, cmp, diff, cksum, etc) and it's repetitive, just write a bash script.
It's not a matter of reinventing the wheel so much as improving it. Why shouldn't you just keep on driving an old electric scooter when you could have a new Honda Hybrid Civic? More powerful without unneccesary overhead, preserving functionality while making it simpler and more straight forward.
When doing Unix pipes, you're stuck parsing text and trying to interpret what one program output and using that. There is no consistency or standard interface. With a setup like MSH (or Perl Shell psh!), your commands can return data structures- objects, arrays, etc- which you can use without wasting your time or computational power parsing and processing.
if you're talking about full-featured programming, regexps and everything then why would you want to do it in a shell script.
I don't know if you've ever done any shell scripting, but regexps are very much a part of what you have to deal with. Things aren't just a matter of piping, with one program knowing what to spit out so that the other program knows. On Unix, regexps are pretty much how you deal with that.
Why should I have to write an ugly C or C++ app to do something relatively simple and straightforward just because my shell language is inadequate? That adds up to a ton of wasted time. There is no reason a shell shouldn't provide the features of a real programming language- as long as it doesn't get in the way of using it like a shell. (E.g. Scsh does, IMHO)
psh never really seemed to take off but it let you basically enter a perl debugging session but execute shell commands also. This would basically trump anything msh could muster and also provide the entire universe of CPAN to the shell.
.NET API- that psh as I use it now does not, putting it in the position to *be* trumped by MSH rather than the other way around. Hell, MSH, with Perl.NET installed, could just as easily use all of that CPAN stuff as you could in vanilla psh.
.NET.
First- on OS X and Linux, I use psh. I love having a real language as my shell, no need to write little glueish C programs or look up really (more than perl sometimes!) obscure bash syntax. As far as Unix shells go, it's definately top shelf.
But I don't think it could trump MSH- unless we were talking about Perl.NET running psh on Windows or under other OSes using Mono. MSH has some serious strengths- like having access to everything going on in the computer, all of the
But, put psh on top of Perl.NET and we've got a really capable setup. Sign me up! Perhaps psh+mono could be the OSS/FS community's answer to MSH on
And, presumably by that prime developer you mention, MS Research has a Haskell-like language for .NET. All the convenience of .NET and its API with none of tha pain in using a sucky language like C++ or C#.
And as for returning search results as .NET objects? This seems rather like using a baseball bat to swat a fly...
.NET object is an 800 lb gorilla. It's jut an object. And being an object, rather than a file or text in a certain format, binary or text, it's ready to be used in your script or application, without having to read in, parse, or otherwise make the output or file actually useful.
,NET object is just an object. Really not all that much more overhead compared to using printfs or spitting it out to a file and then writing your own code to process that text. Why not cut out the middle man?
Certainly doesn't seem that way to me. It's not like a
When writing shell scripts on Linux or Mac OS X, there have been a million times where I've wished the output of a redirected/piped Unix command was available to me in an immediately useful way- rather than to have to write a bunch of regexes or parsing function. It's a pain in the ass. I'd love for ps to return a dictionary (hash, map) of my processes, I could spend my time writing the code that actually did something, rather than parsing the text.
A
Except, as unfortunate as it may be, the shells we use in Linux today for the most part are 80s (or older) technology, but then again, so is MS's CMD.exe. But this new MSH setup isn't the same old kruft that's kept around because so many things use it- it's a new shellwith total integration. The ability to call into any library on the system. I certainly couldn't do that with bash.