There is something interesting there, not sure exactly where or how this fits in. Not sure exactly what purpose the ratings serve. It is not like a particularly good comment stays on the screen very long. There is something good here and there is something missing, I just dont know exactly what that is.
As far as "Less is More" goes, this could be practiced in other languages by voluntarily choosing a simpler subset of features in a language with a complex feature set. Think RISC style in CISC architecture.
Thank you for the reply. I've had some opportunity to work with Python, read some other people's code, and yes Python lends itself to regularity of form. If you squint and turn your head a bit, you can almost see the abstract syntax tree that the compiler ought to create. That is beside the point I think. For me the most difficult thing in maintenance is understanding the intention of certain functions, classes, methods etc. Why did the original author make the choices that he made? What exactly was the intent? Sometimes the accompanying commentary is short on those details. Commentary on why a particular design choice was made and what the intent of the design was is many times more valuable to me when I maintain code.
Can you go into more detail about how Python fixes maintenance? I'm really curious what language features of Python are conducive to good or easy maintenance, and how those features are unique to Python. Color me skeptical, but I can be convinced.
I think he might be referring to the "write once, run anywhere" slogan, about how Java via the JVM would free users and developers from the tyranny of any particular OS.
I can't really see this working in my current line of employment, warehouse automation. Once a system is in production we're lucky if we can deploy a bug fix once a fortnight.
okay, how do you associate photos, videos, emails, driving directions, and a formal invitation booklet that you received as a PDF with that cruise in the South Pacific several years ago to see the total eclipse. If all those electronic artifacts aren't "files" and the collection of them is not a "folder" (<rant>it's a directory damn you heathens !!!</rant>) that documents your trip how exactly do you organize your stuff ? Do you tag each and every object with the word "South Pacific Eclipse Cruise?" in the application that you use to access it? How do you find all the pieces associated with that trip? How do you find out if you do have a copy of that invitation booklet? I'm wondering how to practically move past "files" and "folders" ? (<balmer-rant>Directories, Directories, Directories .... </balmer-rant>)
how is this any different from any other army's entrenching tools? Yes there are a few extras added to it but it is not in any way more ingenious than what's already available elsewhere.
In my experience when working with Java the old Borland JBuilder worked well and was reasonably responsive, Eclipse was a pig no matter how I tweaked it, Netbeans kept me happy.
Hey, wouldn't all that MS has to do is use a different Agent string for IE8 so that the agent sniffing fails. You know, go incognito, like user-agent JF-8.
Hey, I like to make a buck just like the next guy, but it still sounds like a neat thing to work on. I'm sure you could find a way to charge someone something after developing this.
> ... A useful voice interface requires an entirely new UI paradigm.
I think this would require natural language processing far better than what we have now and great deal of contextual knowledge as well as a great deal of "common sense" built into the software (agent? interpreter?). Mice and keyboards remain easier to work with.
Thanks, I'm aware of Comet. Not exactly what I meant, in Comet the connection stays open after being initiated by the client. I'm looking for something where the interaction is first client-to-server, then client registers a "callback" address and port that it will listen to. This would be followed by a server-to-client call where the server will send updates/events to client as they happen, the client then decides what to do with those events. I want to avoid a persistent connection, and either the "heartbeat" client requests or other forms of polling by the client. The interaction that I'm looking for is more akin to a P2P sort of model.
Find a good way to have an asynchronous feed back from a web server to a web client, a true general purpose "push" protocol as an extension of HTTP. Hey you can even call it HTTP2W or HTTP2HTTP. Of course you'll have to come up with not only the protocol definition but also a reference implementation for both the client and the server. Sounds like fun, eh?
This reminds me of an in-house parser of graphing software files that we use to populate physical route information for warehouse control systems. We also used certain naming and icon conventions to express particular semantics that the parser would then convert to the base physical routing maps for a routing engine.
I like how the post focuses on the practical aspects of using Lisp first. I'm just a novice autodidact when it comes to Lisp, but the thing I absolutely love when learning or playing with the language is the interactive top level. I use SLIME on emacs when playing with Lisp at home. It reminds me a lot of the interactive top level available with most good RDBMS manager apps for use by DBA's and developers (TOAD, SQL Navigator, etc). It makes the work go by quickly and you manage to accomplish a lot. In contrast, when at work developing mostly Java web apps, web services, and stand-alone apps, progress comes seemingly much more slowly.