Slashdot Mirror
Why Can't We Put a BASIC On the Phone?
theodp writes "In the Sixties, we could put a man on the moon. Nowadays, laments jocastette, America's tech giants can't even put a BASIC on the phone. Woz managed to crank out a BASIC interpreter for the 6502 in the '70s. As did Bill Gates and Paul Allen. So, why — at a time when development has never been easier — can't Google, Apple, and Microsoft manage to support a free BASIC or other programming-for-the-masses development environment on desktops, laptops, tablets and phones?"
My limited experience with Android development showed using Java to be obtuse and downright obnoxious to do anything (at least without Eclipse, and even with it doing anything non-standard required digging through horrendous ant buildfiles). And, of course, without a REPL things were even more obnoxious. There is the android-scripting project, but it doesn't provide particularly exhaustive access to the platform.
If you say so. Sounds like you haven't done too terribly much with python. I dislike a lot of things about a lot of languages, but I can't say that any of them (well maybe except PHP) are "horrible." I despise curly braces but I can't make the claim that Java is a "horrible" language. Some are more awkward than others sure. There are many things you can complain about in python but whitespace formatting falls pretty far down the list. Having a 1:1 correspondence between my psuedo-code on paper and python code is extremely nice and productive too. Broken web sites and e-mail clients do make cutting and pasting python code problematic, I'll grant you that. But my experience with python has been much the same as ESR's. (And he had the same initial reservation as you.)
I am bitter that Epiphany chose to tear out python and replace it with Javascript of all things. Sort of makes sense given that Javascript is an integral part of browsers. But still makes me sad. Python is such a good language for writing extensions in.
You nailed that one as far as I am concerned.
This week's project for me... I have this old DOS based SPICE analyzer I really like. Its short, simple, and generates great plots - on an old EPSON dot matrix printer.
Now, I really want to get rid of that printer. That old spice analyzer is the only thing I have that requires it. What I really want is a bitmap image file that will go into anything. So, its time to dust off the ole Borland Turbo Assembler.
I plan to hook the printer interrupt and divert the printer data to my program just like a printer capture program, but instead of just capturing the data to a file, I will take it byte by byte and convert it to bitmap format. Lots of rotate-thru-carry instructions to rearrange the data intended for the printhead into bitmap format. Its a state machine, so there is a 6-way switch for the incoming byte to be tested for "esc", tested for "L", tested for "2", store hi-byte, store lo-byte, and append into bitmap. This is easily done in assembler with an index to an array of pointers to subroutines.
( easy in C++ too, but I was having trouble trying to insert the data, delivered to the printhead 8 bits at a time, in a vertical format, into the bitmap when the assembler would let me use the "carry" bit to transfer the incoming byte bit by bit into the most significant bit of eight bytes in the bitmap). There is a helluva lot of looped busywork to rearrange all the bits.)
Being all the plots are generated by the same program, all have the same size and use the same control-code sequences so I do not have to reconstruct the entire esc sequence interpreter of the Epson printers.
I haven't had this much fun since reading Jeremy Bentham's "TCP/IP Lean" where he implemented state machines in C++ to make TCP/IP stacks, and I wanted to modify it so I could get bidirectional file transfer through the "FORM=FILE" method.
That's the fun of this. Doing things that are not on the menu.
As far as Basic goes, I actually still use my GWBasic interpreter at times to verify some little math loop. Its like using a hand calculator in a way, its a short sweet way of running a snippet, but I would not want to develop "serious" code on it any more than I would want to design my bitmap generator in DEBUG.
I do enjoy doing things the old way on my old machine, where I understand exactly what and why I am doing anything, and know exactly what every byte in the code does. Its something I do not know in the new machines, and I can easily end up using hundreds of kilobytes of code along with megabytes of required libraries to execute some little algorithm I could code in assembler for 4k bytes or so of code. Its almost like trying to buy a house, signing off on reams of legal documents I do not understand, just to say "I agree to buy this house and I will pay for it in monthly payments of whatever. If I do not pay, you have the right to take the house back".
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
While I am very reluctant to mention this problem : speed. Now I am very, very tolerant of speed issues in scripting languages, as I know it doesn't really matter. But python ... python is an absolute disaster. Python claims execution speed doesn't matter because it's easy to use, then encases your legs in concrete. The argument justifying that one ? "It's very easy to move 0.01 cm".
So here's the issue : you always get the impression python can be used to do calculations, python claims to be capable of them. And indeed it's syntax seems to allow for more. So let's compare:
1) C, C++, hell even Java : c = a+b (1 assembly instruction)
2) CPython: c = a + b ( > 2500 assembly instructions)
This means that a C program running on an 8086 will actually calculate faster than a python program running on a current pc.
The speed of CPython is so bad that it regularly becomes a problem, and requires all sorts of complex solutions from massively parallellizing using numpy to rewriting half the project in C/C++. That's my main gripe with python. And numpy may approach (from a large distance, but at least not a factor 200 anymore) the performance of normal C/C++ loops, but if you use a numpy like vector processing library in C/C++ (there's many) you're back to a factor 200 or more distance from numpy.
Second is memory usage. I made the mistake of loading in a year's worth of monitoring data using the obvious method : a class representing a datapoint. Result : 12 GIGS (in C++ doing the same thing to the exact same data resulted in 120 megabytes) ... Yes, again numpy can solve this ... but only by greatly increasing complexity and destroying the utility of 90% of python's language features.
Third is the fact that python is very much a typed language, but the only available variable type is a void*, and it actually allows changing the type of a variable, which is a horrible, horrible mistake (and why ? out of some sort of obligation to the idea of dynamic languages supporting this monstruosity). Same for adding members to class instances after creation time. Horrible.
Fourth, the massive complexity and time-dependencies that result from actually using dynamic aspects of the language, introducing tons of non-obvious dependencies on the exact execution order of the program. If these features are used they directly lead to classes that only become valid useful objects after 3-4 method calls and dependant on all sorts of stuff succeeding. Our style guide outlaws actually using the features that make python dynamic, and I doubt we're the only ones.
Fifght, the fact that the dynamic nature of python makes it very hard to document libraries that make use of it.
Sixth, you can't use static analysis on python programs. So ipython just about the best possible autocomplete you can get (ie. autocomplete can only work by executing the program you're trying to develop)
*sigh*
Program a bit in haskell. Now, haskell's pedantic too, no question there, but you will find 10 places python could be improved before you even get through the tutorial.