My coworkers have been arguing the importance of Lingua::Romana::Perligata for months.
I feel that its not so important for the imediate development of Perl, but it is an interesting experiment in language design in general. Almost all programming languages take context from a terms position within a larger statement. Its such a universally implemented method that most people didn't even consider other ways of defining a language. Having each term define the role that they play in the expression is an novel change and allows people the ability to consider to alternatives to positional context.
The PIC web server had support for SLIP. It was connected to a PC which had ethernet on one side and a serial port on the other. Essentially acting as a router. I guess they could have replaced the hardwired serial connection with a pair of MODEMs, but that would have cut its bandwidth significantly.
I don't quite understand your criteria for what is "real Internet connectivity" and what if fake. MODEMs are real but serial cables are fake. PPP is real but SLIP is fake. What makes some criteria valid and others not?
You are missing part of their business model, they are not only selling the bar code to the web site (so that when you swipe the bar code on the Ben&Jerry's you go to their web site.) But they are also selling the demographic information about your swiping habits.
Since each Cue Cat has a unique serial number, they can be keeping track of each item you swipe. Don't you think that Ben&Jerry would like to know that you also swiped a Gaviscon bar code, or a Britney Spears CD.
Since they seem to be so concerned with people disassembling their device and disabling their EEPROM, it seems that losing their profiling data is their real fear.
Intel has always made a wide variety of microprocessors, not all of them being x86 compatible. They have the MCS-51 series 8-bit microcontrollers. They have the i860 RISC line.
They have a large R&D budget for x86 compatible development, since that is a large part of their revenue, but that doesn't mean that is all they know how to do. Neither does it mean that they won't spend money developing an incompatible product line if there is money to be made from it.
As others have written, this new product is the latest development in a product line that Intel bought a few years ago from Advanced RISC Microdevices, (with some fabrication plants they bought from Digital.) These products are geared towards a high MIPS/milliwatt ratio, so they have often been used in portable devices (ie PDAs like the Psion, the Apple Newton Messagepad, etc.)
So no, Intel doesn't expect you to throw away your x86 based desktop for a ARM RISC box. It would be a poor use for the technology. (For a desktop, you have plenty of power, and you can disipate a lot of heat. The perfect environment for a Pentium based CPU because it needs a lot of power and generate lots of heat.) But on the other hand, imagine how smart of a smart phone someone could make with a chip like the strongarm.
"Object Pascal" is the name of an Object Oriented Pascal that Apple computer made in the '80s for Macintosh development. It was a refinement of "Clascal" a language that Nicolas Wirth worked on with Apple when on sabatical in the early '80s. Object Pascal was a language with single inheritance, all methods virtual and all data members public.
Borland's first Pascal with Object oriented extentions was Turbo Pascal 5.5 in 1989, and it was somewhat similar to Apple's Object Pascal. The object-oriented extensions to Pascal released with Delphi was very different (the option for non-virtual methods and access control to data members, and the constructor destructor definition was entirely different.)
Re:Overanalyzing the definition of "OS".
on
Is UNIX An OS?
·
· Score: 1
The definition of operating system that I was taught was the "software that controls the allocation of resources" definition that others have already re-iterated. According to that definition, DOS was not an OS, since it did little resource allocation (and what little it did was bypassed for BIOS or direct hardware access) CPM, on the other hand was an OS.
Java wouldn't be an OS, but with a little JNI for hardware support, you could build a Java based OS.
Re:but Unix doesn't handle all hardware...
on
Is UNIX An OS?
·
· Score: 1
Don't blame Unix for shortcuts made by the XFree project. Many vendors who make hardware designed to run Unix put access to the video through a device driver.(Sun's/dev/fb* devices.) XFree decided to violate the lines between the hardware controlling operatings system and the OS accessing application.
Of course, people making their own hardware have much better control over what a video device looks like, and makes it easier to write device drivers for. Shortcuts were probably taken to avoid the pain of writing device drivers for the wide variety of Unix varients that X86 runs on.
In perl they aren't required, and then you have to keep doing use strict to find bugs
But "use strict" doesn't force the programmer to declare types, it just requires the programmer to declare variables. The variables remain varients with implicit type conversions. For a description of strongly typed languages without explicit type conversions (and how it contrasts to Perl) take a look at Strong Typing
Why shouldn't one of the primitive types of a language be that of an address ?
Pointers also prevent a lot of compiler optimizations due to aliasing issues. I'd rather have a highly optimizing compiler that knows how to do all the neat pointer tricks rather than one that is kept intentionally dumb because it can't tell when I'm doing neat pointer tricks. (Of course I'd also like more communication between the compiler and the linker so that virtual methods could be converted to static if not overriden.)
By puting things in terms of "Assembly language to Visual Basic" you are really defining the terms of language design really narrowly.
Basically you're just analyzing one axis of the evolution of programming languages,(the pure imperitive branch) from the Assembly to Fortran to Basic to VB (with a few backwards steps with GWBASIC and QBASIC in there.) Its not that far of a stretch. I plan on taking a close look at functional programming, logical programming, 4GLs, etc. before I ask "is that all there is".
I worry about the way you dismiss object oriented programming so quickly too. The way objects work in C++ vs. Smalltalk vs. Python vs. Dylan shows a huge range of study just to decide what objects are and how they work.
I'm sorry, I was just talking within the single-click vs. double-click context. Teaching "left-click to select an object, right click to see the things you can do with that object" is a pretty reasonable rule to teach beginners too. And you are right that enbolding the item that is the equivilent of double-clicking is a good memory enforcement strategy.
The only drawback with teaching contextual menues so soon after selecting with a mouse is that with a pop-up contextual menu, the user is relying on objects that are hidden from their sight. When teaching selecting and picking items from the menu bar, you can ensure them that all of their answers are right in front of them.
For the Macintosh, double-clicking isn't needed for anything. It is a shortcut for "select this object" followed by "perform the obvious action associated with this object."
You don't need to (and shouldn't) teach novices double-clicking at all. Teach them selecting objects with the mouse, then teach them selecting actions from the menu and they are immediately able to be productive. The double-click shortcut can be taught later as a quick side topic to people who seem to be getting the hang of things.
Windows95 unfortunately introduced some UI elements that can only be activated by double-clicking, so that ruined my old response to the "should I single-click or double-click" question. I used to just answer "you don't need to double-click anything. select it with the mouse and then select what you want to do from the menu." (anybody who needs to ask has missed some concepts and should be sent back to novice mode.) The multibuttons on unix seem to run from one extreme to another. Either they are very consistant within themselves but unintuitive (I'm thinking about things like Open Look) or very inconsistant.
Instead of using a natural language system for something like this, why not just use something similar to Apple MPW's commando system. Any command preceded by "commando" or suffixed with the ellipse character (option-;) brings up a dialog box with all (or at least most) of the options and arguments a command takes as radio buttons, checkboxes, file pickers, and fill in text boxes. At the bottom of the dialog it shows the command as it is being built. With this system, you can use the dialog box as a guide if you can't remember the syntax to a command, but it doesn't become a crutch that you need to keep using.
I wouldn't describe put source into container as the canonical form of get expression. The original form was get expression and then put source into container was added to the language to support additional variables.
When Bill Atkinson was adding scripting to his Rolodex program (and yes, he did get in trouble for using the name Rolodex) and turning it into Wildcard (which unfortunatly was someone elses trademark. Eventually Apple picked Hypercard because it was such a dumb name, it wasn't taken yet.) At first he was planning on just some action parameters to the program, and was figuring on one "accumulator" like location to hold info. When they scope of Wildcard grew from flatfile database to hypertext authoring system the scope of the scripting language changed, named local and global variables were needed, and the accumulator turned into the variable it.
Signal 11 was at least on the right track, even if he had some of the facts a bit off. There were certain things that would only modify the contents of it, so put it into|before|afterdestination was probably the most frequent statement in Hypertalk scripts. Certain noise words like the and to were allowed in order to help readability, but it was difficult to remember which constructs allowed them and which did not. (The statement delete word 3 of field "high score" worked but delete the third word of the field "high score" didn't) This tended to make Hypertalk easy to read, but harder to write. Not the ideal for a natual language style CLI, like we are discussing, but not bad for a programming language designed to foster cut-and-paste ad-hoc development.
The syntax style lives on in the Applescript (and a bit in MacroMedia Director, but they seem to be moving away from that with their "javascript-style" language.) Maybe the verbose "english style" language was a good choice for AppleScript. User scripting of desktop applications probably does have a lot of cut-and-paste style of code reuse. And someone is probably going to be able to figure out what is going when seeing a snippet of Applescript over VBSCript (one of WSH's choice of languages.)
The people who chose to use Hypertalk-style languages were really missing the point of what made Hypercard such a great development environment. The best thing about it was the lack of destinction between development mode and running mode. It was kind of like a baby-smalltalk or baby-lisp environment. So many people are enamored with interpreted language that cut the edit-compile-link-run down to edit-run, or with IDE's that hide the compile-link phases down to a single keypress or menu-selection, that they don't realize that even edit-run isn't a distinction that needs to be there. At the Perl conference Damian Conway and Aaron Wigley gave a talk about Llamacard, a Hypercard-like environment written in Perl and extensible with perThis l. It looks like something I really want to play around with.
The cuisenart style Macs with the built in monitors (the original Macintosh, the Mac 512, Mac Plus, 512E, SE, SE/30, Classic, and Classic II) were produced between 1984 and 1994. The screen size doesn't distinguish it as first generation.
The monitors on those machines were monochrome, not greyscale. Unfortunately the original Macintosh Toolbox was built around the idea of 1 bit per pixel, and the first color machines (the Macintosh II, in 1987) caused the first "ugly backwards compatibility hacks" that have just been heaped and heaped on the OS for the next dozen years.
That statements a little disingenuous. The original filesystem on the Macintosh and the Macintosh 512. What was later called the MFS file system; the one for 400K diskettes and no real folders. That filesystem allowed 255 character file names.
By the time Apple got to the Mac Plus, Apple was trying to develop filesystems that would scale better to larger filesystems and created HFS. At this time, they reduced the number of characters in filenames from 255 to 31.
So yes, Apple had 255 character filenames from day one, but they didn't have them on day 750 through day 6000. (750 being approx the number of days between the release of the original mac and the mac plus. 6000 being approx the number of days between the 128K mac and the public beta of OS X)
Your making a couple of leaps in your reasoning here.
The Unix community has been doing the "multiuser, multitasking thing" for many years. And for some of those years some developers have actively been seeking the best performance possible. (And at other times, especially earlier in Unix's history, people have been working toward the "small is beautiful" goal more than looking toward developing high performance environments.) Linux has been around for a few of those years, but since it is a reimplemntation it might not be on par with every performance tweak of every Unix developed ever.
You can't say that since Unix is a mature platform with lots of work has been done to make various versions of Unix very efficient, that Linux, a reimplementation of Unix, should be very efficient as well.
But in the Apple User Interface Guidelines, double clicks are never anything that can't be done without the menubar. Double-clicking can be counter-intuitive, thats why when ever I explain things, I never give the "double click" shortcut. Its always "click on the icon, now go to the file menu and choose open". When someone is familiar enough with the system to know that double clicking is the same as choosing the default action, they'll start doing it on their own.
Don't go pointing to studies done on Windows to show inadequacies of user interace design in general. We all know that Windows shouldn't be held up as the user interface poster boy.
This all sounds well thought out, except that timing is all wrong.
Microsoft was selling mice by the early to mid '80s, before the release of windows. (Multiplan and Word were both MS-DOS applications with mouse support) but the first couple of releases of windows had no contextual menus. (I'm talking about Windows 2.1, 3.0, and 3.1) It wasn't until Windows 95 that Microsoft used contextual menus (maybe there were some applications that were released soon before 95 with contextual menus. But those were done with full knowledge of the direction of Windows 95)
So are you trying to say that Microsoft started selling two button mice because 10 years later that were going to start introducing contextual menus?
And I'm not sure I buy your argument that contextual menu were developed to make up for badly designed hotkeys. I alsways thought that the Windows 95 developers lifted from the OS/2. Whoever put them into OS/2 probably was very familiar with the Smalltalk environment, since it seems to be a reimplmentation of the "yellow button."
This is newspaper journalism, transplanted onto the web. Newspapers don't (didnt'?) want to lead you to information, they wanted you to think that you needed to keep coming back to to them get it.
I considered You Better, You Bet when I wrote that. I had actually pulled out the two LPs to be sure I wasn't also falling victim to to an age-distorted perception. And it is a good song, but not one of the ones for the history books.
And thats just one song out of the two albums I mentioned. In the '70s, it was hard to pick one out of the many great tracks on each record.
But look at what you are doing here. The major record labels are essentially giving you two choices, and you align youself with one because you dislike the other. You're allied with "Eurasia" since you have been told to fight "Eastasia".
Find music that you really like, even if you have to go beyond companies with RIAA membership. Don't take what you are spoonfed, Thats how the current state of popular music got into the state its in, by the music industry slowly leading the public to the safe choices until there is little choice left.
Slashdot Mirror
I feel that its not so important for the imediate development of Perl, but it is an interesting experiment in language design in general. Almost all programming languages take context from a terms position within a larger statement. Its such a universally implemented method that most people didn't even consider other ways of defining a language. Having each term define the role that they play in the expression is an novel change and allows people the ability to consider to alternatives to positional context.
The PIC web server had support for SLIP. It was connected to a PC which had ethernet on one side and a serial port on the other. Essentially acting as a router. I guess they could have replaced the hardwired serial connection with a pair of MODEMs, but that would have cut its bandwidth significantly.
I don't quite understand your criteria for what is "real Internet connectivity" and what if fake. MODEMs are real but serial cables are fake. PPP is real but SLIP is fake. What makes some criteria valid and others not?
- Sun Remarketing http://www.sunrem.com/
- Shreve Systems http://www.shrevesystems.com/
- Pre-owned Electronics http://www.preowned.com
to name a few.You are missing part of their business model, they are not only selling the bar code to the web site (so that when you swipe the bar code on the Ben&Jerry's you go to their web site.) But they are also selling the demographic information about your swiping habits.
Since each Cue Cat has a unique serial number, they can be keeping track of each item you swipe. Don't you think that Ben&Jerry would like to know that you also swiped a Gaviscon bar code, or a Britney Spears CD.
Since they seem to be so concerned with people disassembling their device and disabling their EEPROM, it seems that losing their profiling data is their real fear.
Intel has always made a wide variety of microprocessors, not all of them being x86 compatible. They have the MCS-51 series 8-bit microcontrollers. They have the i860 RISC line.
They have a large R&D budget for x86 compatible development, since that is a large part of their revenue, but that doesn't mean that is all they know how to do. Neither does it mean that they won't spend money developing an incompatible product line if there is money to be made from it.
As others have written, this new product is the latest development in a product line that Intel bought a few years ago from Advanced RISC Microdevices, (with some fabrication plants they bought from Digital.) These products are geared towards a high MIPS/milliwatt ratio, so they have often been used in portable devices (ie PDAs like the Psion, the Apple Newton Messagepad, etc.)
So no, Intel doesn't expect you to throw away your x86 based desktop for a ARM RISC box. It would be a poor use for the technology. (For a desktop, you have plenty of power, and you can disipate a lot of heat. The perfect environment for a Pentium based CPU because it needs a lot of power and generate lots of heat.) But on the other hand, imagine how smart of a smart phone someone could make with a chip like the strongarm.
Borland's first Pascal with Object oriented extentions was Turbo Pascal 5.5 in 1989, and it was somewhat similar to Apple's Object Pascal. The object-oriented extensions to Pascal released with Delphi was very different (the option for non-virtual methods and access control to data members, and the constructor destructor definition was entirely different.)
Java wouldn't be an OS, but with a little JNI for hardware support, you could build a Java based OS.
Of course, people making their own hardware have much better control over what a video device looks like, and makes it easier to write device drivers for. Shortcuts were probably taken to avoid the pain of writing device drivers for the wide variety of Unix varients that X86 runs on.
But "use strict" doesn't force the programmer to declare types, it just requires the programmer to declare variables. The variables remain varients with implicit type conversions. For a description of strongly typed languages without explicit type conversions (and how it contrasts to Perl) take a look at Strong Typing
Why shouldn't one of the primitive types of a language be that of an address ?
Pointers also prevent a lot of compiler optimizations due to aliasing issues. I'd rather have a highly optimizing compiler that knows how to do all the neat pointer tricks rather than one that is kept intentionally dumb because it can't tell when I'm doing neat pointer tricks. (Of course I'd also like more communication between the compiler and the linker so that virtual methods could be converted to static if not overriden.)
Basically you're just analyzing one axis of the evolution of programming languages,(the pure imperitive branch) from the Assembly to Fortran to Basic to VB (with a few backwards steps with GWBASIC and QBASIC in there.) Its not that far of a stretch. I plan on taking a close look at functional programming, logical programming, 4GLs, etc. before I ask "is that all there is".
I worry about the way you dismiss object oriented programming so quickly too. The way objects work in C++ vs. Smalltalk vs. Python vs. Dylan shows a huge range of study just to decide what objects are and how they work.
When you have have programmer's block, don't try to distract yourself by reading slashdot.
It may seem like a good idea at the time, but you will soon realize that your two lines of code productivity will drop in half.
The only drawback with teaching contextual menues so soon after selecting with a mouse is that with a pop-up contextual menu, the user is relying on objects that are hidden from their sight. When teaching selecting and picking items from the menu bar, you can ensure them that all of their answers are right in front of them.
You don't need to (and shouldn't) teach novices double-clicking at all. Teach them selecting objects with the mouse, then teach them selecting actions from the menu and they are immediately able to be productive. The double-click shortcut can be taught later as a quick side topic to people who seem to be getting the hang of things.
Windows95 unfortunately introduced some UI elements that can only be activated by double-clicking, so that ruined my old response to the "should I single-click or double-click" question. I used to just answer "you don't need to double-click anything. select it with the mouse and then select what you want to do from the menu." (anybody who needs to ask has missed some concepts and should be sent back to novice mode.) The multibuttons on unix seem to run from one extreme to another. Either they are very consistant within themselves but unintuitive (I'm thinking about things like Open Look) or very inconsistant.
Instead of using a natural language system for something like this, why not just use something similar to Apple MPW's commando system. Any command preceded by "commando" or suffixed with the ellipse character (option-;) brings up a dialog box with all (or at least most) of the options and arguments a command takes as radio buttons, checkboxes, file pickers, and fill in text boxes. At the bottom of the dialog it shows the command as it is being built. With this system, you can use the dialog box as a guide if you can't remember the syntax to a command, but it doesn't become a crutch that you need to keep using.
When Bill Atkinson was adding scripting to his Rolodex program (and yes, he did get in trouble for using the name Rolodex) and turning it into Wildcard (which unfortunatly was someone elses trademark. Eventually Apple picked Hypercard because it was such a dumb name, it wasn't taken yet.) At first he was planning on just some action parameters to the program, and was figuring on one "accumulator" like location to hold info. When they scope of Wildcard grew from flatfile database to hypertext authoring system the scope of the scripting language changed, named local and global variables were needed, and the accumulator turned into the variable it.
Signal 11 was at least on the right track, even if he had some of the facts a bit off. There were certain things that would only modify the contents of it, so put it into|before|after destination was probably the most frequent statement in Hypertalk scripts. Certain noise words like the and to were allowed in order to help readability, but it was difficult to remember which constructs allowed them and which did not. (The statement delete word 3 of field "high score" worked but delete the third word of the field "high score" didn't) This tended to make Hypertalk easy to read, but harder to write. Not the ideal for a natual language style CLI, like we are discussing, but not bad for a programming language designed to foster cut-and-paste ad-hoc development.
The syntax style lives on in the Applescript (and a bit in MacroMedia Director, but they seem to be moving away from that with their "javascript-style" language.) Maybe the verbose "english style" language was a good choice for AppleScript. User scripting of desktop applications probably does have a lot of cut-and-paste style of code reuse. And someone is probably going to be able to figure out what is going when seeing a snippet of Applescript over VBSCript (one of WSH's choice of languages.)
The people who chose to use Hypertalk-style languages were really missing the point of what made Hypercard such a great development environment. The best thing about it was the lack of destinction between development mode and running mode. It was kind of like a baby-smalltalk or baby-lisp environment. So many people are enamored with interpreted language that cut the edit-compile-link-run down to edit-run, or with IDE's that hide the compile-link phases down to a single keypress or menu-selection, that they don't realize that even edit-run isn't a distinction that needs to be there. At the Perl conference Damian Conway and Aaron Wigley gave a talk about Llamacard, a Hypercard-like environment written in Perl and extensible with perThis l. It looks like something I really want to play around with.
The cuisenart style Macs with the built in monitors (the original Macintosh, the Mac 512, Mac Plus, 512E, SE, SE/30, Classic, and Classic II) were produced between 1984 and 1994. The screen size doesn't distinguish it as first generation.
The monitors on those machines were monochrome, not greyscale. Unfortunately the original Macintosh Toolbox was built around the idea of 1 bit per pixel, and the first color machines (the Macintosh II, in 1987) caused the first "ugly backwards compatibility hacks" that have just been heaped and heaped on the OS for the next dozen years.
That statements a little disingenuous. The original filesystem on the Macintosh and the Macintosh 512. What was later called the MFS file system; the one for 400K diskettes and no real folders. That filesystem allowed 255 character file names.
By the time Apple got to the Mac Plus, Apple was trying to develop filesystems that would scale better to larger filesystems and created HFS. At this time, they reduced the number of characters in filenames from 255 to 31.
So yes, Apple had 255 character filenames from day one, but they didn't have them on day 750 through day 6000. (750 being approx the number of days between the release of the original mac and the mac plus. 6000 being approx the number of days between the 128K mac and the public beta of OS X)
Your making a couple of leaps in your reasoning here.
The Unix community has been doing the "multiuser, multitasking thing" for many years. And for some of those years some developers have actively been seeking the best performance possible. (And at other times, especially earlier in Unix's history, people have been working toward the "small is beautiful" goal more than looking toward developing high performance environments.) Linux has been around for a few of those years, but since it is a reimplemntation it might not be on par with every performance tweak of every Unix developed ever.
You can't say that since Unix is a mature platform with lots of work has been done to make various versions of Unix very efficient, that Linux, a reimplementation of Unix, should be very efficient as well.
But in the Apple User Interface Guidelines, double clicks are never anything that can't be done without the menubar. Double-clicking can be counter-intuitive, thats why when ever I explain things, I never give the "double click" shortcut. Its always "click on the icon, now go to the file menu and choose open". When someone is familiar enough with the system to know that double clicking is the same as choosing the default action, they'll start doing it on their own.
Don't go pointing to studies done on Windows to show inadequacies of user interace design in general. We all know that Windows shouldn't be held up as the user interface poster boy.
This all sounds well thought out, except that timing is all wrong.
Microsoft was selling mice by the early to mid '80s, before the release of windows. (Multiplan and Word were both MS-DOS applications with mouse support) but the first couple of releases of windows had no contextual menus. (I'm talking about Windows 2.1, 3.0, and 3.1) It wasn't until Windows 95 that Microsoft used contextual menus (maybe there were some applications that were released soon before 95 with contextual menus. But those were done with full knowledge of the direction of Windows 95)
So are you trying to say that Microsoft started selling two button mice because 10 years later that were going to start introducing contextual menus?
And I'm not sure I buy your argument that contextual menu were developed to make up for badly designed hotkeys. I alsways thought that the Windows 95 developers lifted from the OS/2. Whoever put them into OS/2 probably was very familiar with the Smalltalk environment, since it seems to be a reimplmentation of the "yellow button."
What you are describing is similar to what Intel wants to do to video displays, as reported here.
This is newspaper journalism, transplanted onto the web. Newspapers don't (didnt'?) want to lead you to information, they wanted you to think that you needed to keep coming back to to them get it.
And thats just one song out of the two albums I mentioned. In the '70s, it was hard to pick one out of the many great tracks on each record.
Find music that you really like, even if you have to go beyond companies with RIAA membership. Don't take what you are spoonfed, Thats how the current state of popular music got into the state its in, by the music industry slowly leading the public to the safe choices until there is little choice left.