HNHacker News
TopNewBestAskShowJobs

mmiller

60 karma · joined April 26, 2007

submissionscomments
mmiller··on Alan Kay has agreed to do an AMA today
I didn't begin to get it until the industry started trying to use browsers for applications in the late '90s/early 2000's. I took one look at the "stateful" architecture they were trying to use, and I said to myself, "This is a hack." I learned shortly thereafter about criticism of it saying the same thing, "This is an attempt to impose statefulness on an inherently stateless architecture." I kept wondering why the industry wasn't using X11, which already had the ability to carry out full GUI interactions remotely. Why reject a real-time interactive architecture that's designed for network use for one that insisted on page refreshes to update the display? The whole thing felt like a step backward. The point where it clobbered me over the head was when I tried to use a web application framework to make a complex web form application work. I got it to work, and the customer was very pleased, but I was ashamed of the code I wrote, because I felt like I had to write it like I was a contortionist. I was fortunate in that I'd had prior experience with other platforms where the architecture was more sane, so that I didn't think this was a "good design." After that experience, I left the industry. I've been trying to segue into a different, more sane way of working with computers since. I don't think any of my past experience really qualifies, with the exception of some small aspects and experiences. The key is not to get discouraged once you've witnessed works that put your own to shame, but to realize that the difference in quality matters, that it was done by people rather like yourself who had the opportunity to put focus and attention on it, and that one should aspire to meet or exceed it, because anything else is a waste of time.
mmiller··on Alan Kay has agreed to do an AMA today
I was fortunate to grow up during a time when Alan Kay was a well-known figure in the personal computing world, and while what he said didn't make sense to me at the time, it still interested me intensely, and I always wondered what he meant by what he said. Strangely enough, looking back on my younger experience with computers, I think I actually did get a little bit of what he was talking about. It's just that I came to understand that little bit independently from listening to him. I didn't realize he was talking about the same thing. It wasn't until I got older, and got to finally see his talks through internet video that I finally started seeing that, and realizing more things by listening to him at length. Having the chance to correspond with him, talk about those things more in-depth, helped as well.

The way I look at it is just take in how fortunate you are to have your realizations when you have them (I've had my regrets, too, that I didn't "get" them sooner), and take advantage of them as much as you can. That's what I've tried to do.

mmiller··on Alan Kay has agreed to do an AMA today
Kind of, but it was clunkier. You could Break out of an executing program, edit the code you wanted, and then type CONT to continue execution from the break point. The state from that point forward might not be what you want, though. At least inside VS it tries to revert state so that the revision executes as if the state came into it "clean."
mmiller··on Alan Kay has agreed to do an AMA today
I don't know in what context "hot editing" was used to start this thread, but what I read in it is the idea that you can change code while it's running. Edit and continue has a different feel to it, because it works by a different method, by literally patching memory that the suspended thread is going to execute. It has the convenience of stopping the execution of the program before the patch is done. What "hot editing" in, say, Smalltalk has been able to do is you can have a live program running, you can call up a class that the thread uses, change the code in a method, compile it, while the thread is still running, and instantly see the change take effect. The reason it can do this is that method dispatch is late-bound. In .Net it's bound early. Late binding allows much more of a sense of experimentation. You don't have to stop anything. You just change it like you're changing a setting in an app., and you can see the change instantly. This gives you the feel that programming is much more fluid than the typical "stop, edit, compile, debug" cycle.
mmiller··on Alan Kay has agreed to do an AMA today
At first, I was tempted to see this as a disappointing comment, promoting the idea of "If you didn't understand this early, you're not going to, no matter how hard you try, so stop trying," but I think what you could really be saying (correct me if I'm off) is that just because you want to do something, doesn't mean you know how to do it. So, trying to change things for the better takes some serious preparatory work that takes some time to do, learning alternate perspectives that will help you understand better what's really going on, and what tendencies people have that can be used, if people are willing, to help them realize what I've just described. However, if you don't have time for that, just acknowledge it, but also understand that you're not going to have a positive impact on that goal, because you haven't gotten out of your common sense perspective and natural urges, which are only going to make the problem worse if you try to make that impact, because you're not going to understand what you're doing. The comment Alan made at https://news.ycombinator.com/item?id=11940497 is indicative of this concern. However, in defense of this thread, I think everything that Alan has been talking about in here is an attempt to guide people toward learning how to learn so that for those who find the opportunity, they can give that advice a try, and see if this really is for them or not.
mmiller··on Alan Kay has agreed to do an AMA today
One thing I've found about the web, as it exists, is that the people who set up a system for the outside world to use change it over time. The URLs change. The CGI their service will accept changes. As things exist now, a program must use "sticky" names, and if a name changes, all of a sudden the connection is broken, even though the exact same functionality still exists. It would be good if a program could find the functionality it needs based on a functional description of what it needs, rather than a name. That gets more to what's really important. I once complained to Alan that Smalltalk had the same problem. If I change the name of a class, all of a sudden all the code in the system that needs that class could no longer find it, even though I had changed none of its functional code. This seemed like an extremely brittle scheme for finding resources. The name is not the important thing about what a program needs. It's just a reference point that does nothing. Names are still good, because they allow us to quickly identify resources, but they should mainly be for us, not the program, because when you really think about it, a program doesn't care what something is called.
mmiller··on Alan Kay has agreed to do an AMA today
Re. consider "send processes rather than messages"

Interesting thought to ponder!... What came to mind is Smalltalk-80 kind of did that, though the processes (blocks) were not in the "driver's seat" of the interaction. They came as "payload."

mmiller··on Alan Kay has agreed to do an AMA today
As Alan has said, the importance of funding is more about finding the problem. There's a lot of wandering and false leads involved (though, finding out the false leads is nevertheless valuable. It's still new knowledge). In terms of hardware, the thing to anticipate is what computing power will be necessary for accomplishing things decades from now, and paying the bill for that, not considering what one can buy from a computer retailer today, because that doesn't create the excuse to think of what computers will be able to do.
mmiller··on Alan Kay has agreed to do an AMA today
The problem with the idea of procedures acting on data structures is that as a system scales up, it gets more complex in terms of its data structure, and the amount of code that must operate on it, and be dependent on it. As that happens, it gets harder to change, both in terms of the structure, and the procedures that work on it. The dependencies between the structure and procedures grow in number and type. The attempt to understand it creates a cognitive load that makes it difficult and inefficient to keep track of them (if not impossible), and keep consistency in how they operate. Secondly, the amount of code that's required to operate up to spec. becomes so voluminous that it creates a cognitive load that is too much to handle, in terms of finding and fixing bugs.

Part of scaling is understanding the relationship between what is necessary to express to carry out the complete, intended model, and the number of relationships (the best I can express this is "in chunks") that we can keep track of simultaneously. Modern engineering in other fields of endeavor understands this notion of cognitive load and complexity, in terms trying to organize resources such that a constructed structure can carry out its intended function well as a result of principled organization methods.

mmiller··on Alan Kay has agreed to do an AMA today
I think another way of looking at what you said is people can feel threatened or diminished by certain arguments, even if they're not directed at them, when certain cherished premises are challenged, and part of learning to argue well is to learn to take those feelings as signals that the argument needs to be looked at closely and seriously, but not as truth. It's not the final word, but more checking needs to be done to see if one's own premises are close to reality or not. Of course, that always needs to be done, but from what I see, many people are not equipped to deal with an argument that hits a nerve, much less to listen to ideas that don't agree with each other, and consider the argument based on its content, not on attitudes ("What it sounds like or feels like").

Since "fast and slow" have been a part of the discussion here, perhaps what I'm describing has to do with the relationship between "System 1" and System 2?

mmiller··on Alan Kay has agreed to do an AMA today
Take a look here:

https://tekkie.wordpress.com/2010/07/05/sicp-what-is-meant-b...

mmiller··on Alan Kay has agreed to do an AMA today
I won't presume to speak for Alan, but my understanding of what he's said is very different historically. As I recall, he said that the first Macintosh was "the first computer worth criticizing" (something like that). When Jobs introduced the iPhone, he asked Alan whether it was "worth criticizing," and he said no, but if Jobs were to make it a certain size (I forget the dimensions he mentioned, but one of them was 8"), he would "own the world." This suggested the iPad, which did become very popular, though arguably the iPhone became even more so.

I remember one thing Alan said (this was a couple years after the introduction of the iPhone, but I think it was before the iPad), which relates to your question is, "I wish they'd allow people to program the darn thing," which I took to mean, "program on the darn thing!"

Tablet computers existed long before the iPad, though they were bulky and expensive. I used to write software that ran on Telxon tablet units back in the mid-1990s, which used WiFi. A bit later they got enough memory and processing power that we were able to run Microsoft Windows on them, though they cost several thousand dollars each (not a consumer price point). I remember in video of a reunion of former Xerox PARC employees (around the year 2000. It's on the internet), Chuck Thacker held up a Tablet PC running Squeak, and he said, "This is a Dynabook right here." That sort of thing is more of a Dynabook than the iPad, because the software development licensing restrictions for iOS don't even allow people to share code from one unit to the next, because it's considered a security hazard. Apple let up on the restrictions such that people could write code on them, in an environment such as Scratch, but they're not allowed to share code from unit to unit. Instead, they have to jump through hoops, posting code on a web server for others to download.

Part of what the Dynabook was supposed to do was allow people to share code without the thought that it was a security hazard, because it would be designed to be a safe environment for that sort of thing. The iPad has the hardware form factor of a Dynabook (if I may say so), but its system ideas are far from it. It's designed as a consumer product where people are supposed to use it for personal interaction, gaming, consumption of digital content, and little else.

mmiller··on Alan Kay has agreed to do an AMA today
Indeed.

I think another part of it was people wanted to go on using systems the way they had been, with the operating system being a base layer on which things happen, which does not exist as a foundation for building a different system. To create code, you put it in files, files go in directories, you compile it into a static executable, which becomes temporarily dynamic when executed, and then goes back to being static when it exits, because it was based on a static image. The OS makes it difficult for the executable to update the state of its own image, assuming that trying to do so is a mistake. You run it on top of the OS, not in the OS, not part of it. It's the recapitulation of the application metaphor, where the app. only exists while someone is using it, and then all its state goes away when they're done with it, unless a small piece of it is serialized (unpacked into raw bytes, with no meta-code) for later retrieval. With that kind of setup, the thinking is there's no need for inter-entity relationships that become part of the larger whole, though eventually people wanted applications systems with capabilities, and so more cruft got added onto the pile, trying to create versioned late-binding in the midst of a system designed for abstract data types.

When I talk to people about OOP, I explicitly try to distinguish it from ADTs and systems like I've described above, though I'm at a bit of a loss to come up with a phrase for what to call languages that people commonly call "OO." I've sometimes called them procedural languages, with an extra layer of scoping, or that work with ADTs, but that's a mouthful.

mmiller··on Alan Kay has agreed to do an AMA today
To provide a little hope, I think it should be pointed out that the Frank project (VPRI) achieved web browsing that is compatible with the existing web protocol, using real objects. What it allowed is an extension of browsing on the web. So, it's not as if the two (good architecture and bad architecture) can't both exist in the same space, and be used at the same time. I think the key to answering your question is asking will people in the general public find the impetus to understand the limited nature of bad architecture, and (on one possible track) either use the good architecture to make the experience better, or (on another possible track) come up with a better computing/content architecture that does away with the web as we know it altogether?
mmiller··on Alan Kay has agreed to do an AMA today
This is the way Facebook is now... Not an improvement. It's not designed for following threads, and it looks like they don't care.
mmiller··on Alan Kay has agreed to do an AMA today
What you ask here is very interesting to me, because some time back I got to thinking about what Alan Kay talked about with trying to negotiate meaning, in reference to using Licklider's concept of "communicating with aliens." Kay (IIRC) used a simpler concept of trying to order a burrito from a vendor, where neither the vendor nor the customer understand each other's language. He said by using gestures, you can get the idea across, because you can reference common concepts in each other's heads, and finally come to agreement about ordering a burrito. So, I started on a "sketch" for a language for a fairly simple task (converting between encoding schemes) where the code was suggestive, rather than prescriptive, and it just used a declarative style. One example is I just said, "a5 b6 10..." (including the double-quotes, and the trailing "...") to try to suggest a string containing a sequence of hex numbers of indeterminate length. I was saying, "Expect this type of information." As I did this, and thought about what else the language would need to express, I came to the exact same question you did, "There could be a variety of interpretations of this. Maybe the dev. environment should ask the programmer questions, 'Did you mean...?'" The programmer could respond in some way meaning "Yes" or "No." If no, the dev. environment could ask about other possible meanings it knows about, based on the syntax used. I could see this getting complicated very quickly, because what I hoped for was that the language would give a programmer the freedom to try expressions that made sense to them, in hopes that the language environment with which the programmer communicated would understand them, and that the language environment should try as "hard" as it could to understand them. However, not being skilled in AI, I wondered if the forms of expression I was thinking about were constrained enough in meaning that I could completely code a scheme whereby, looking at syntax "signals" in the code, it could reason through the expressions to make good guesses about their meaning, and then test them by formulating intelligible questions about them to confirm what the programmer was getting at. Going through that exercise told me I had a lot to ponder, learn, and explore with this idea, because I didn't come up with any ready answers that felt satisfactory. The best I could come up with was that I would code the language to allow a few possibilities with the syntax "signals," in combination with other "signals" that I could anticipate, but if the expression went beyond the coded meanings, I'd have to have the language say, "I don't understand what you're talking about. Please try expressing it differently," which would lead to a kind of guessing game between the programmer and the language, with the programmer quickly getting the idea, "There have got to be some rules to this system. Why don't I just look at its programming, and figure out how I use its rules to express what I want," which would defeat what I was going after. The whole thing would be an artifice, rather like an Eliza simulation.
mmiller··on Why People Don't Like Nerds or Programmers (In School)
I think he makes a good point in that nerds tend to exclude themselves, but I think it's a defense mechanism from being rejected. Believe me, when I was in jr. high and high school (more than 20 years ago, now) I wanted to "join the crowd" badly. I wasn't allowed in, and I felt awkward every time I tried to join in. I just didn't fit the social milieu. I didn't feel the need to exclude others (there's a difference between this and excluding yourself). If someone else wanted to be my friend I gladly accepted them. So I don't get this whole thing about how "nerds exclude everyone else." That wasn't my experience.
mmiller··on Using Lisp at Paragent
Amen. This kind of attitude is promoted by people who want to do what Paul Graham did, use Lisp as their "secret weapon" in a startup. I find this attitude dispiriting. How are people going to realize better forms of computing if they're discouraged from looking at the good stuff? How are we going to solve the problem of 80-90% of software projects failing if people are only encouraged to use mediocre technology. This isn't good for society.

I see some of this same attitude in the Squeak (Smalltalk) community, though it's not as bad. People are more willing to share it with others.

mmiller··on Using Lisp at Paragent
It makes sense that Lisp would run well on Lisp machines. I don't know why Symbolics didn't succeed more than it did. Alan Kay has complained that the hardware architecture that started in the 1970s and became dominant was deficient. It might've become popular just because it was cheaper. It didn't run Lisp or Smalltalk well at all, and so they were "killed", to use Kay's term. The languages people became familiar with were driven partly by what became this dominant computing platform; languages like BASIC, Pascal, and C, and all of their follow-ons. This platform grew way faster than the Lisp machines did. Unix essentially rode that wave with the "worse is better" approach. In comparison I'm sure the Lisp machines were considered proprietary, and "weird" or obscure.

What probably also did damage to Lisp's popularity was a perception problem. I talked about this in another comment in this discussion. In the schools Lisp was taught almost exclusively as an AI language. Scheme was different. I remember when I was in college the engineering school taught their students Scheme, and had them do all of their programming assignments in it. But within the CS schools Lisp was seen almost strictly as an AI language. I think this limits its appeal. If students took AI, they learned more about it, if they specialized in something else they learned Fortran, Pascal, and maybe C. Thats was it. AI was such a specialized and problematic field to begin with as well. It seems that hardly anyone saw that Lisp was just as good of a general computing system as C and Unix is on traditional processors.

Smalltalk is the same way. I remember I was taught it (briefly) as a programming language, even though it started out as the operating system of the machine it ran on. It has a rich history, yet most people who have even heard of it think of it as just a language that runs on a VM, which is actually a screwed up way of looking at it.

Another aspect to it is Lisp represents a very different view of programming. Most kids/students are taught imperative languages as their first language. This is encouraged all through school. By the time they meet Lisp it's a bridge too far. That's how it was for me years ago when I first encountered it at school. I had a terrible teacher, so I got no help there, and Lisp was so alien it made my head hurt. I couldn't figure it out. It wasn't until I found a good teacher, and then some good reading material on it in the years that followed that I finally began to grok it a little.

mmiller··on Using Lisp at Paragent
Complexity of implementation? Slowness? Lack of marketing? Unfamiliar syntax? No, none of these explain the lack of popularity.

I think you dismiss these factors too quickly. We need to remember that even seemingly little things can prevent adoption.

C and C++ have been running fast on cheap hardware longer than Lisp has. The reason Lisp has caught up in performance is because of (relatively) better CPU architecture.

Marketing played a part in Java becoming popular. I can point to a few reasons:

- The language designers modeled it after C++, a language many developers were familiar with.

- Sun sold it as being more multi-platform than C++.

- It was "internet ready", unlike C++. This was a HUGE factor. No other language that people knew of made this claim. If developers used C++ on the web it was in combination with Perl, and only on the server.

- They touted its garbage collection capabilities. No more having to free memory--something C and C++ developers were concerned about. It looked and kind of felt like C++, but without the hassles. That's how it was billed.

- It ran in browsers as an applet, and was securely sandboxed. This was something no other language could do (initially). They caught the "internet fever" at just the right time with this message. Lots of people deployed applets. Eventually Microsoft came out with its own solution: ActiveX. Along with Flash, it effectively killed Java applets. Why? Java applets were problematic. They didn't run well across browsers (partly by design--Microsoft and IE). Flash integrated multimedia more easily than Java did. Nevertheless, people found that Java was more cross-platform than C or C++ on servers (though you had to be careful about your brand of JVM).

On the minus side, Java had its detractors regarding performance. I think this became less of a problem on the server. People "just threw hardware at it", until it ran fast enough.

I listened to the Java evangelists for years. So I know what their developers were excited about. The main thing for them was the slogan "Write once, run anywhere". They loved it. What sold Java to the enterprise was J2EE, an enterprise framework specification, which Sun implemented for Java. They built upon their installed base over time.

Sun showed corporations how using Java allowed customers to choose their hardware based on capability and price more easily, since "you don't have to rewrite the app." That was a key phrase--keep your software investment no matter what hardware and operating system you choose. They differentiated this against the Microsoft ecosystem. Nevermind that for many customers this didn't always work out. There were JVMs that had incompatibilities with each other. Despite Sun's claims that Java programs don't crash the machine, I saw it do just that in its early days.

What mattered was the idea, nevermind the reality: perfect portability, and internet-ready. Corporate customers liked that. Programmers liked that it was "a better C++". It took a language they were already familiar with and made it "better". That's what customers were after, and they thought only Java could deliver it.

One might ask if this is the case why didn't Objective C take off? That's a bit of a hard one for me. It was a favorite among NeXT developers. Ever since the early to mid-1990s it's been implemented in GCC. My guess is there was no corporate support behind it by then. Objective C was initially marketed by a single company in the mid-1980s. It was never recognized as a standard. You had to buy it from the company that created it. Eventually it went out of business, I think, but it did effectively become open source. Today it comes on the Apple Mac, so it has corporate sponsorship now. The Mac's popularity is growing, so perhaps this'll translate into success for Objective C someday.

Corporate sponsorship of languages carries risks, but it can also encourage adoption. If the company that owns the language implodes, it takes the whole community down with it--I refer you to what happened to Smalltalk. Microsoft was just more successful with VB. I could tell you a story about the beginnings of BASIC's popularity, but that would be getting off-topic.

I haven't been keeping track of market share numbers, but if it's the case that Java has overtaken VB, I can give a couple plausible reasons for it, the gist of it being Microsoft screwed VB developers. When MS initially came out with VB.Net it was a major departure from VB 6, the previous version. For most people VB.Net could not translate or run older VB programs. It would try to translate them, but major parts of applications had to be rewritten, because they took out support for some things the VB API used to do. They implemented things differently. They made programming in VB more complicated, so there was a significant learning curve to get up to speed.

C# initially got all of the advantages. Most of the early .Net documentation was written only for C#, not VB.Net. Most of the early .Net code demonstrations were done in C#, not VB.Net. C# had some cool features VB.Net didn't get initially. If you were a VB developer you felt left out in the cold by MS. Some VB developers became C# developers, just to make the transition easier. There were endless debates on MS forums: "Should I learn VB.Net or C#?" There was uncertainty in the VB community about its future. Some migrated over to Java, figuring it was a skill they could invest in and not have to change like they did with VB.Net. So MS in effect "anti-marketed" VB.

You may remember there was a lot of buzz about XML some years ago. The main reason being that it was an "internet ready" meta-language for data. Are you noticing a theme here? "Internet ready" is key. If it's not "designed for the internet" people will turn their nose up at it. Note this is a marketing message.

Re: XML

Microsoft actually did something slightly innovative: They invented the technology that enabled AJAX. They put the XMLHttpRequest() call into IE 10 years ago. They added built-in support for XSLT as well. OWA (Outlook Web Access) was one of the first major AJAX apps., before Google Maps. As you may remember, anything MS pushed got adopted by a lot of people back then.

Why did XML work? It was initially sold strictly as a data description format. I think, like Java, it kind of looked familiar to developers. Getting people to adopt HTML in the 1990s was a learning curve. What was the "killer app" for that? The web. You couldn't be on the web unless you dealt with HTML. That was enough motivation for people to learn it. Once they learned HTML, they only had to learn a design construct to get XML. The same tagging syntax was used.

Using XML to do actual programming didn't come along until later. People looked for a way to end the tedious repetition of code. Some people found a way to get XML to act as a meta-language. Like XML it was descriptive. Everything was labeled. It was "just text" so it was "internet ready" as well. It didn't require a lot of thought either. None of the XML tools I've heard of have a sense of recursion, which is hard for a lot of people to understand.

Why has Ruby become popular? Two answers: Rails, and DHH, who knows how to market a product. Before Rails came along Ruby was as obscure as APL. Rails not only made Ruby "internet ready", it added an extra dimension that web developers have been craving: instant gratification. The idea that you could design your web app. from your database--basically data-driven development--was like a dream come true. The same way that the internet drove people to learn HTML (an unfamiliar syntax), Rails has driven some developers to learn Ruby.

In order for a technology to coax people to learn it, despite it being unfamiliar, it has to have a "killer app", which is something that's compelling (answers an immediate desire or need), and is the exclusive province of that particular technology, at least for a little while. We've seen this again and again.

Perception is a big part of whether a technology takes off or not as well. How has Lisp been "marketed"? For generations, it seems, Lisp has been billed as an AI language. So if you're interested in exploring how people think, or how a machine could think, this language was for you. How are people supposed to go from this to thinking, "Oh yeah, I could use that for my next web app."?? In order for marketing to work you have to show people how the tool or system answers a need they have. It needs to be sold to them as something they can relate to. One of the problems with the Lisp community, so I hear, is this is a real challenge for them. Making Lisp something exciting and relevant seems to be as hard for them as trying to explain market economics or politics to a 4-year-old. The truth is it's not too hard. As you point out, syntactically XML is like Lisp. I tried pointing this out in a blog post once, and I got a bunch of negative responses: "I HATE XML!! Why would I like Lisp any better if it's like what I hate?!" Oh well... :(

Something RMS talked about is years ago when Emacs was first being developed, someone tried introducing Lisp to non-programmers by making it part of Emacs, and not using the word "programming" at all. They merely said, "If you'd like to add convenient features to the editor, you need to describe your feature using these features and syntax." It was successful. The key was, "Teach programming while people are doing something else." Don't teach programming as an end in itself. Teach it as a means to an end that they want.

Here's a hint if anyone wants to take it up. There's an open source project out there called "Vista Smalltalk" that works with WPF, WPF/E, and Flash. It's a way to create RIAs (Rich Internet Applications). It runs both Smalltalk and Lisp code. If anyone's interested in evangelizing Lisp in a way that people can relate to, this is an opportunity to do it.

mmiller··on Using Lisp at Paragent
"Worse Is Better" is an old article, I think from the early 1990s. Back then Lisp did run slowly. I can remember taking a course around 1989/1990 that had us running the n-queens problem in Lisp. People would start up their n-queens programs on Unix minis and leave them running unattended, to go away for lunch or something. The programs ran for hours. This is the reason why Gabriel talks about scale (memory size) and performance. Today these are not really issues anymore. I can run the same n-queens program on my PC and it'll take just a second or two to run. That's a dramatic difference.
mmiller··on Does anyone code Smalltalk any more?
The $100 laptop (also known as the OLPC--One Laptop Per Child project) is not based on Squeak. It's partly based on Linux (the OS), but the stuff users see is largely written in Python. Squeak is on the laptop as one of the things students can use. I think the main reason it was put on there was for its eToys facility, which allows kids to draw objects on the screen and then program them to do things, to create their own simulations. It also has some games that run on it.

It's on there as part of the open source spirit of the system as well. Since Squeak reveals all of its code in Smalltalk, once they learn the language they can explore it and modify it however they like. The same goes for the Python stuff.

Re: Croquet

Yes, Croquet is written on the Squeak VM. It's actually based on a modification to Squeak, called "Tweak".

IMO Smalltalk is worth checking out. I've been doing so. There are different paths you could take with this. The basic level you can explore is the Smalltalk language itself. There are online books on the language you can read. There are some hardcopy books that cover the higher levels of Squeak. There's Morphic, which is the window manager for the Squeak desktop environment. There's eToys, which is a more abstract, but easy to use, scripting environment. Then there's Seaside, which is a web application framework for it. There are no books for this. The best source I've found for it are blogs that focus on Seaside.

Seaside uses some advanced programming constructs to create a programming environment that's unlike most other web frameworks out there. I haven't used it directly yet, but from what I've read about it, it's really nice. If you get into it you probably won't want to go back to what you used before.

mmiller··on Is Java dead?
This is like PG's post on his blog, "Microsoft is dead". Don't declare stuff dead so soon. I still remember Byte Magazine declaring "Object-Oriented Programming is Dead", and within a month, "Unix is Dead". Both deaths were greatly exaggerated.

Re: Java, it sounds like the excitement has died, but neither Microsoft nor Java are anywhere near dead. In fact, what has really died in the computing world, besides coding in machine code/assembly language, punch cards/paper tape, and teletypes? And aren't we thankful for that? It seems like every other computer interaction idiom is alive and well.

Some things don't stay dead forever, either. Dynamic languages could've easily been declared dead 13 years ago, without exaggerating, but they've been making a resurgence recently.

mmiller··on Microsoft is Dead
Your thesis is based on the idea that Microsoft is dead because nobody fears them anymore. I think this is the wrong way to look at it. Does fear = relevance? It can, but how many people fear IBM? I doubt many. IBM is not dead. It's come back from the ashes of the late 1980s. They used to be feared, but I don't think that's the case anymore. Probably the only company that does fear them is Sun.

I think one reason people are less afraid of Microsoft is they're doing things that are less scary. I agree with one commenter that customers might fear them more than entreprenuers do. They're gradually making their client technologies more cross-platform, not Windows specific. Customer requests were probably a big part of that, but it may reflect a change of consciousness on the part of Microsoft's workforce, too.

I think Microsoft will remain relevant, just less scary.

I think Google's gotten a little scary with the deal they made to censor search results in China. They found an exception to their "don't be evil" motto.

← PreviousPage 2 of 2