ObfusCo > The List > lang

Programming Blog

Dream Programming Environment

"Compared with what could be known, we have very, very small heads."
"Syntax is the Vietnam of programming languages."
"A language that doesn't affect the way you think about programming is not worth knowing."
"Learn Haskell you Microsoft hippies." (I think that was said before it became ironic.)
"To think deeply and well about iterative, imperative programming you need to be a Dijkstra, and even then the results are very ugly. Whereas other programming paradigms do afford that kind of thinking better."

(I put together a little laundry list of desires.) I am getting really sick and tired of developing using tools from, what, like the 50's or something? Anything with a slow, required, compilation step sucks! Also, it seems like language creators (see the miscellanea in the long list below) either don't actually know anything about generics, co vs. contra variance, type vs. implementation inheritance, etc., or they made strange choices because they thought the general programming public couldn't handle the knowledge and responsibility? Weird. Well, still, there are some pretty crazy cool languages out there, though: Mercury (doesn't yet have a quality Java or .Net back-end), Arc, (but i want static type inference/checking!), Merd (no 'e'? :-), Clean (gave up on it as soon as i saw there was no debugger), O'Caml (nowhere near portable enough in my experiences), Haskell (too much !%$@<<=, and i despise whitespace-sensitive indentation, no debugger?), Timber (will it ever be released? will it have a debugger? news at 11), Nice (lacking fancy automatic type inference on the order of Scala, but has optional types and nice sugar), Scala (over the top type annotations), Eiffel (love that contract idea, hate that Alogl syntax) and Qi (just scary Lisp drugs, man!).

• Also: Java notes.
• Also: Eiffel IDE.
• Also: C++ notes.
• Also: Visual Cafe IDE.
• Also: Visual Age IDE.
• Also: JavaScript (and related AJAX-y stuff).
• Pretty much, LtU (if only the quotes) subsumes this entire page!
• Also check out PLNews.
• The People Projects and Patterns wiki is another interesting place.
• The Journal of Object Technology has intersting articles.
• Artimia has food for thought.
• Don't forget the venerable comp.lang.* newgroups.
• There are always various forums and blogs worth reading (if only to learn new slurs).

• If you find an article that is locked, you might be able to find it unlocked.
• 704) It is pretty amazing how bad Erlang's error messages are. (Like, it cannot tell you what line it blew up on. Like, sometimes it gives information but only to say what is wrong, not why, e.g. "module name in object code is echo" is trying to say that the CWD is such that it thinks the module name should be something like src.testerl.echo.) So much for it becoming the next big thing for everyone to use for concurrency. Now, if the Scala Actors library can get some real-world testing time on it...
• 703) It bugs me that Erlang uses capitalized words for variables and lower case ones for atoms. I would have done it the other way 'round, so I find it very confusing to read and write Erlang code.
• 702) Run-time stuff sucks, but so does the expression problem. I wonder if PMD [pdf] really helps or if it just makes everything so dynamic that if there's a bug you are really in heck?
• 701) FP vs. OO, fight!
• 700) The idea that you can just make things nicely abstracted and encapsulated is a pipe dream. Just think about all the issues that come up with that most basic necessities: equals().
• 699) The approach taken by Teracotta is food for thought for any system that has some VM layer (.Net, Erlang, Smalltalk, etc.). The super big red flag for me, however, is that they use byte code injection and I've never had too experiences with that. Sure, you might get away with one tool doing it to your code, but as soon as you try to have yet another tool doing more injection, things fall apart.
• 698) More argument in favor of functional style [pdf] for software development, in particular for dealing with object identity, especially in light of distributed systems.
• 697) Some concurrent constraints for Java, motivated by the fact that concurrency in Java just plain sucks. Possibly more fun than a Java programmer should be allowed to have; it reminds me of Timber. The thing that strikes me as most obviously scary is, how on earth are you going to debug code in that style? If you are going to get into concurrency, wouldn't it be good to offer some kind of checks and constraints to try to alleviate or prove freedom from the cabal of concurrent troubles: deadlock, livelock, race conditions, etc.?
• 696) Yet more fun stuff [pdf] to read, let alone comprehend.
• 695) It comes as no surprise, but remember that no matter what systems you use, they don't entirely save you from having to understand and think. Dogged! Remind me to read up on some network formality which might help avoid nasty deadlock etc.
• 694) Nothing is perfect, and I'm sure Ruby is no exception, but it can still be pretty cool (of course, similarly Python and perhaps less similarly Perl).
• 693) Just how far could regular tools get us towards robust code? (SPARK Ada is probably even more anal.)
• 692) OK, while this formalization of Aspects [pdf] is cool, you have to wonder what kind of code would actually be generated in the end, and how much of a nightmare it would be in terms of debugging and maintenance. Being forced to only go one way in the model (not being able to edit the final source code and have it automagically update the model that generated it in the first place) sucks, in reality.
• 691) I guess if I really got into Erlang, I would want to grok distel to boot.
• 690) What do you do when your system is too complex to reason about formally? (Not that most folks even think to try to do formal reasoning about what they are building.)
• 689) Some interesting notes re: synchronous vs. asynch message passing, a la Erlang, Alice, Ada, etc.
• 688) I feel like this whenever somebody tells me that C++ is so great. But that's just me.
• 687) All I'm saying is, I think there is possibly a moral in this tale about stronger typing, and contracts.
• 686) Interesting to hear different takes on garbage collection.
• 685) I wish I were smart enough to draw up a table explaining the subtle differences among all the implementations of subtyping.
• 684) A little history of Haskell.
• 683) How to guarantee no deadlock [pdf] in your system.
• 682) There's a lot of synchronicity about concurrency research these days; most everybody can agree on the fact that they want to avoid classic "mutable share state" approaches, and we're seeing more of the Erlang message-passing and E event-based stuff in other languages [pdf].
• 681) Back when I was a kid, we only had one qbit, and we were lucky!
• 680) I hope that Lisp never dies. (Although, generally speaking, I'd prefer to use Scheme.)
• 679) Wow. Talk about geeking out. Super nerdy cool.
• 678) It appears that Erlang has dieted, although I have to say having yet another packaging system off in its own little world is never the best idea, to me.
• 677) Is it me? Or did they never say why ?! [pdf]
• 676) Pretty-print your souce code the old-school way [pdf].
• 675) To quote Homer: "in your face, Perl!" [pdf]
• 674) Those whacky O'Caml kids just don't stop.
• 673) Haskell's software transactional memory looks good [pdf]. I'm not cluefull enough to know how it compares or might complement the concurrency unification work.
• 672) A little list of functional languages. Whacky stuff.
• 671) On unifying concurrency, which should be of interest to anybody who has looked at the Erlang vs. E concurrency debate.
• 670) One problem with all the monad tutorials is that they bring in all this cruft for something that doesn't require cruft when done in other languages, so you are always left wondering - from a very mechanistic, low-level perspective - why monads are needed. I think this helps answer that question.
• 669) Some day I'll maybe get a chance to try to grok the Zipper FS.
• 668) Yes, Virginia, there are functional quantum programming languages.
• 667) I've been following Scala which sits on top of the JVM, but Nemerle seems to be darned nifty as well; it targets MSIL (so maybe I could use it with Mono). The only thing is, it appears to still be kinda alpha.
• 666) Remember: sqrt is slow in any language, including Haskell.
• 665) The use of upper case in the syntax is atricious, but the more I read about occam (and, better yet, occam-pi), the more exciting it sounds - my honeymoon phase with Erlang is over, so next up is this stuff.
• 664) I had my hopes up that Erlang plus tools like Dialyzer would rock, but reality sets in, inevitably. Perhaps I should be learning more about the pi-calculus for a robust solution?
• 663) Everything you ever wanted to know about lambda calculus reduction.
• 662) How to write a client-server app in Erlang, of course.
• 661) If you are willing to take it on faith that set theory can be the basis of programming languages, it might be worth reading this little screed on Lambda-ness [pdf].
• 660) I dunno about you, but it kind of scares me that even the gurus find concurrent / asynchronous / distributed systems to be a real bear.
• 659) Worth a look, Stackless Python offers cheap and easy threads much like Erlang - and AliceML, etc. - although realize that Erlang goes to great lengths to keep things as individual processes, not as threads with share mutable state.
• 658) Learn how to solve Sudoku in Haskell, not so you can cheat on the newspaper ones, but so you can see iterative development in practice.
• 657) A desire to bring mechanically verified software to us all, hopefully making systems that much more robust. There are even some already available 'solutions', although I'm guessing they are not so understandable to your non-ivory tower software engineer.
• 656) How to do polymorphic variants (think "visitor (anti)pattern") in Haskell.
• 655) You just gotta love Prolog, and you gotta love Prolog Programming Contests [pdf].
• 654) It bugs me that really important things are not properly encoded into our programming languages. A couple of examples: Monads are not really enforced too strongly by the Haskell compiler; Immutability is an agreement done at the documentation level more than at the language level (although some languages have 'const' or 'final' they aren't quite the same as marking a complete object as entirely immutable). One obviously avoids having any update methods, but the issue of communicating to a user of your API that something is immutable and having the compiler and run-time guarantee that for everybody isn't really resolved.
• 653) Every home-grown distributed computing solution grows and bloats until it contains a half-assed, bug-ridden implementation of JINI. That's the markeing claim, at any rate.
• 652) Basically, it seems to me that we'll never get OO right just because there are a zillion ways to skin that cat (and we can't even all agree on precisely what cat it is we are skinning).
• 651) The images are screwy (at least in Firefox), but learning Cocoa via F-Script might be fun to do some rainy day.
• 650) More than you ever wanted to hear about GC in C++ (ha ha).
• 649) Blow your meta-mind [pdf].
• 648) Some notes on how to make the wild web safe via academic, ivory-tower, high-falutin' research.
• 647) Whacky 3D games in Haskell [pdf].
• 646) Gosh, what could be better than FRP & GADTs [pdf]? (Of course, FRP isn't for everyone or, more accurately, everything.)
• 645) While this article is somewhat Java-specific, I think it still contains relevant thoughts when dealing with exceptions in other languages, too.
• 645) Ever more evidence that C++ is kinda pure evil.
• 644) How to [pdf] speak tersely and carry a powerful programming language.
• 643) A la Python comma Monty, Cobol is not dead yet.
• 642) Alan Kay speaks about the 'ma' of languages.
• 641) It is claimed that exceptions will make life easier, in some sense, yet they tend to change things, sometimes making things harder to reason through.
• 640) Oh, right, of course! now it is all perfectly clear.
• 639) The study of 'types' is deep and complex, and certainly never fully understood or exhausted. As complex as things are, the idea in hiring somebody smart to study them for your problem space is to leverage their power to avoid confusing cruft that we see in systems all the time.
• 638) Sure, I7 is cool and all, but natural language-like systems are fraught with peril.
• 637) Objects (as in OOP) are overrated. Also, some thoughts on all the object-like-things from which a programmer can choose (well, if they are using O'Caml, at any rate).
• 636) Apparently, LolliMon is cool.
• 635) Use Prolog to rule the stock market.
• 634) I'm sure this will be a light read: Category Theory for Dummies [pdf].
• 633) Some misc classics on Mass-Produced Software Components, and Software Reuse Myths.
• 632) More good O'Caml tutorials mentioned.
• 631) For those of you who don't know Scala, now is your chance to learn up.
• 630) Erlang lives on, in Lisp.
• 629) Interesting exception hacking in TCL.
• 628) This particular discussion on LtU is of interest, if only to remind us that math, er, programming languages are hard.
• 627) Dataflow programming is interesting, although generally kind of hard to do in ASCII. Well, apparently here's an attempt of sorts.
• 626) Oh, those whacky O'Caml kids just won't stop.
• 625) While I'm not smart enough to really grok types as far as they can really go, I do like trying to get the jist so I can use a language that is more robust.
• 624) Perhaps a classic, an intro to Occam [pdf].
• 624) Good to see dataflow / functional-reactive stuff growing. Interesting to see related ideas.
• 623) Some more thought on how some OOP sucks; you get entirely too much coupling and inflexibility. (Check some alternatives)
• 622) Speaking of exceptions, the idea of dynamic recovery, rather than static, pre-defined everything, is interesting and has long been part of Lisp and Smalltalk. (And the sense of humour in the Lisp debugging environment, with "pointer into hell" messages, is cute.) And: a related philosophy for error handling in Erlang. On the other hand, smart people prefer termination over resumption, well worth considering. (Note, however, that I think resumption would be good to have as a tool up to the actual shipping date, for debugging purposes.)
• 621) It is interesting to think of having a system that is coherent and robust and yet still performant enough to let you treat everything as a program, including the debugger, rather than viewing such as some arcane special case.
• 620) If you are stuck with C++ or Java, you could make use of the ACE libraries to implement concurrency patters, e.g. try to make some mini-Erlang. (Personally, I suspect I'd rather stay away from C++ at almost all costs, and just use Erlang.)
• 619) Qi-like, but more statically checked [pdf].
• 618) If you are stuck doing some procedural-shared-mutable-state type programming, and you want your systems to not fall out of the sky, there might be something to be said for the fact that Ada isn't dead yet.
• 617) You know you want to learn about static typing, in Perl to boot!
• 616) I think these folks are cool (in a nerdy kind of way).
• 615) I always liked SML because once you got the program to compile, it generally had no logic bugs in it. The problem is then - unfortunately - getting it to compile.
• 614) This is your brain. This is your brain on bi-directional programming [pdf].
• 613) I sure hope Timor pans out to be really real some day.
• 612) Awesome! There are Abelson & Sussman videos on-line!
• 611) Avoid wailing and gnashing of teeth: learn some history and theory.
• 610) O'Caml certainly does a good job advertising itself via the expression problem. Check out some other notes on that classic issue.
• 609) Some interesting takes on typing dynamic languages, including type feedback (which is very JIT-y).
• 608) If Oleg is to be believed, one can and should write exception-free code in Haskell.
• 607) I don't know if this is funny or sad.
• 606) The other problem with syntax is that it has to cover so many use cases; the same syntax might seem to make sense in one case and yet seem pretty evil in other cases / to other people's eyes.
• 605) I appreciate that Java tried to simplify things. I appreciate that C# lets me make things on the stack as well as the heap. I don't appreciate when offering the choices leads to complexity. The holy grail should be that everything has simple, consistent, and succinct syntax yet lets us do things either way. I guess auto-boxing goes some way in that direction?
• 604) At least with some compilers I've used, multiple inheritance in C++ falls apart when you try to cast to the various base class types. That's because the compiler laid out the base class structs one after the other, but no matter what you casted to it would return a pointer value to the first struct. Nice.
• 603) While I'm ranting about C++ (and Java!) I'd like to note that I really dislike silent magic language features because down the road you find code that is harder to tease apart because magic things happen e.g. static_cast<RWTime>(*this) += 5 secretly creates a new RWTime and calls a copy constructor. Or e.g. that in C++ (in theory?) if the base class destructor is virtual, then all the subclass destructors will be virtual even if you fail to declare them thus - yet that doesn't hold true of other functions. Even in cases where it isn't that convoluted, like "friendly" visibility in Java, I wish it were just made explicit with a keyword.
• 602) I love how in C++ you differentiate between the prefix and postfic operator++() with a dummy int parameter. Couldn't we have languages with syntax that is flexible enough to not lead us into this kind of crap one or two revisions down the road?
• 601) Funny how most of the web pages regarding C++ or Java interview questions fail to define "polymorphism" sufficiently, in my opinion. To me it just means we all suck at defining and communicating.
• 600) I find it funny that we come up with abstractions that we then have to write lots of tutorials about to explain what is going on underneath the abstraction. What if, for example, instead of using the keyword "virtual" in C++ we used "runtime" or "dynamic" or something which more clearly explained what it caused to happen? (Oh, and then we go and make it more confusing by calling it "static" binding, ha ha!)
• 599) While Erlang and such ilk are favourites of mine, at least in comparison to the usual ghetto of shared-state concurrency, there are of course always issues to carefully weigh.
• 598) You can do ever more with REST, including possibly interesting robust concurrency.
• 597) Another shot in the RIFE vs. continuations debate.
• 596) A nice tool that lets you extend Python in Python, rather than requiring you to hack into the Python interpreter. Kinda nice and Lisp-y.
• 595) You have to love anything named MetaBorg. (It is all about embedding/extending via domain specific languages. Apparently.)
• 594) There are many important aspects of a software system that are hidden, buried in the ASCII source code. For example, threading issues are classicly a huge pain in the ass to divine and resolve. When are we going to get really good compositional programming with good visualization?
• 593) I appreciate that Lisp's syntax lets it do all sorts of cool things really easily, but at the same time it seems like bad UI.
• 592) Java vs. Erlang smackdown. (I really like Tate's Crossing Borders series.)
• 591) Someone famous who turned in his Lisp hat for Python (and who now works at Google). Includes a little Lisp/Python comparison cheat-sheet. (Also, for those who think Lisp is slow, there's a nice performance comparison showing CMUCL to be pretty kick-ass. It is funny to note that the compiler for CMUCL was, at least at one time, named Python [acm]. Interesting how they hilight the intellectual bankruptcy of everybody who pushed off language concerns by saying, "oh, the compiler will just [magically] take care of it". It is kinda like when programming languages do not have a multi-line comment character, and they say "the IDE will take care of it".)
• 590) Holy heck, I've got a lot to learn (and re-learn).
• 589) It isn't just that other languages have different syntax than your run-of-the-mill Java or Perl, it is that they can do pretty fundamentally different things. (Sometimes, those things are wildly complex and confusing, sometimes they are Gordian Knot solutions, sometimes they are in-between.)
• 588) A rant index with articles seen previously.
• 587) ML functors are well worth groking. The bonus there is a nice little explanation of how parametric polymorphism is a specific type of polymorphism. (Reminds me that I only wish Alice had a debugger, so sad.)
• 586) Possibly furturistic programming via composition.
• 585) Concatenative languages are oft maligned for reasons that make some sense to me, but it appears there are still plenty of interesting ideas in them.
• 584) If you are stuck doing basic Java development, FindBugs is one of the coolest things ever.
• 583) Damn, I love being reminded that C++ is hard. I kinda really hope I never have to deal with it ever again. Or, that I can hire the smart experienced anal people to deal with it all.
• 582) The Ptolemy stuff looks to be very powerful, in the realm of constructing coherent concurrent systems.
• 581) I really would like to grok safe concurrency - I just haven't had the opportunity to really dive into some nice concurrent programming.
• 580) Ever more to read on a rainy day: Solution-Based Modeling vs. Business Object Notation vs. Object Behaviour Analysis.
• 579) I am always depressed that O'Caml on MS Windows continues to suck. I guess the idea that Cygwin would just make Unix things magically work on Windows is crap (I already knew that, by the way).
• 578) The OBJ languages sound pretty neat; they leverage logic to get nice specification and verification capabilities. The Maude Primer [pdf] seems to be written in an accessible style.
• 577) OK, so I'll be writing the video game server system in Erlang, and the client code in Cyclone.
• 576) Remind me to learn up on genetic programming.
• 575) Guess we should all read A Practical Theory of Programming.
• 574) Barbie says, computers are hard.
• 573) While a little overly long-winded, defmacro's Lisp tutorial is worth a read.
• 572) Check out a video about django, which is the Python alternative to Ruby on Rails, it would seem. (Interesting to see the politics of software engineering behind it all.
• 571) Classic problems, ever over again.
• 570) I wish Scala all the best, but I think they have clearly shown signs of screwing the syntactic pooch.
• 569) Looks like Erlang is getting some sincere flattery.
• 568) Remember kids, concurrency is hard. You could use the old semaphore based approach, but that sucks. There's a range of alternatives: Message-passing a la Erlang. Communicating sequential processes which is now even available for Java. Check up on the E vs. CML fight, er, mutual learning experience; E uses event loop concurrency.
• 567) Wirth just keeps going [pdf] and going.
• 566) Remind me to write some adventure games.
• 565) Some thoughts on how to automatically optimise your code.
• 564) Why complexity kills [pdf], and perhaps what to do about it. I like the part that, as I read it, rants against the "unit tests eschew the need for static typing" school. (I just wish they didn't use bloody italics everywhere.)
• 563) Here's an ode to stronger typing.
• 562) Wadler waxes eloquent on functional programming.
• 561) It is interesting that audio processing has its own entire sub-culture of languages.
• 560) A fine question: why Hecl?
• 559) It is the same old story: there's solid research out there and everybody ignores it until driven to implement it in, say, the next version of Java or C#, whence they can claim to be studly smart for having introduced it to the world. Retch!
• 558) Hm, will Ruby on Rails never catch on? Some pretty good points are made.
• 557) It is turtles - er, reflection - all the way down. Send them money.
• 556) It is interesting to see the E language community still chugging, making interesting contributions to the idea of robust software.
• 555) Haskell and Excel, a match made in... you decide.
• 554) A lot of programming is hard. So when I hear people say they love C++, or Haskell, or something equally 'powerful' I have to wonder what they would do if Scott Meyers or Oleg Kiselyov didn't exist? Even Java, which was supposedly kept really simple, still needs smart people to explain those simple things. I don't know what it all means, other than that when it comes time to work with other people you should strive to find folks who have more experience and who are smarter than you are for the languages you are using.
• 553) I kinda think it is funny when functional programming actally learns something from imperative programming. Of course, when the functional / applicative folks get interested they come up with a lot more math-type-stuff than you run-of-the-mill OO person. I wish these kinds of things were also presented in a more boiled-down and pragmatic way so that functional languages didn't keep their image of utter esoterica. As an aside, I particularly liked the comment in the articles that a programming language without a good macro system (hygenic? syntax-case?) starts to go awry when it adds syntactic sugar for library calls. Really, while macros are potentially dangerously powerful, I think a 'real' language must support them, or some other nice way of modifying itself.
• 552) So far, I have found Jython to kinda suck, so I wonder if JRuby is any better?
• 551) The Scala community seems to be gathering steam: Some blogging about it, and some whacky examples.
• 550) F-Script sounds kinda neat.
• 549) The world of O'Caml cracks me up because of all the spin-offs; G'Caml, Fresh O'Caml, yadda yadda yadda. Don't get me wrong, it is great that O'Caml has been so useful for researchers to try things out.
• 548) Personally, I think the Praxis folks [pdf]. are kinda geek gods.
• 547) Maybe CDuce is cool, after all? (I'm always suspicious of anything that claims to be stupendous just because it deals with XML.)
• 546) It is funny to me how languages start out simple, in the sense of offering only restricted power so that they aren't overly confusing, and eventually people get around to totally generalizing things because in the long run that's more powerful, and you will need it?
• 545) Some helpful Erlang conventions.
• 544) It bugs my sense of simplicity when I see things like Java and Erlang requiring one to have a filename match the name of the thing the file contains. Why not derive the name automatically from the filename, or just let the filename be anything?
• 543) Given how the proper use of exceptions is more religion than science, I found this note about Smalltalk's exception handling to be really neat: you really can resume from where the exception was thrown, once you handle it. That seems really cool, in a "Lovecraftian madness" kind of way. (Of course, Lisp always has something to offer in the way of ideas.)
• 542) I wish I had time to learn everything.
• 541) OK, sometimes I think computers are hard. I guess it just reminds me how little of things I really grok; I understand the general ideas of closures and continuations and threads, oh my, but there's plenty of detail in them to fully understand [pdf].
• 540) I think Monad will be pretty cool.
• 539) Get your parallelism for free! Almost. Kinda. If yer lucky.
• 538) The sub-culsture of SML implementations is rapidly gaining members, perhaps to some day approach the long laundry list of Scheme systems?
• 537) Higher-order datatype generic programming, in Scala.
• 536) Why don't we have systems like this that just work, and that everybody is using all the time?
• 535) Teach yourself the lambda calculus (the notes are in PostScript).
• 534) Some food for thought about how repetitive and silly all our OO coding really is.
• 533) While the slide show's UI is sorta sad (you can't resize the slides), there are some nice pithy ones in there.
• 532) Free Lisp training.
• 531) So you say you want a Haskell tutorial? We'll, I'll give you a Haskell tutorial: bend over!
• 530) Any paper which uses the word reify [pdf] pretty much sets off strong "this is crap!" alarm signals for me. But you should see for your self.
• 529) The internals of C++ compilers are a pretty funny joke!
• 528) I don't yet know Python super well, but I hope it brings functional programming to the masses.
• 527) Aspect-oriented tools always seemed a little cheesy to me, but I could see how they might come in real handy for debugging. The claim that it is good for modifying production code to get new features is, in my mind, pretty short-sighted; I think that if you go down that road you will all too soon end up with a nightmare of layers of AOP code. While the first couple of rounds of AOP stuff might be easy and serve their purpose, I just can't see them as viable in the long term when new requirements cause there to be new interactions among all the layers of code. Even for relatively simple stuff like logging, AOP seems like a band-aid solution because we don't have the right tools for the job: while the pointcuts can abstract away some of the system, allowing the underlying system to change without forcing the AOP stuff to change, there are probably still many ways in which changing the underlying code will force AOP changes. In particular, any change in the higher-level semantics of the system would do it - if you are using AOP to, say, print out some member state variables for logging and debugging, if those variables change their purpose then you might have to change the logging-via-AOP code. Is there any way to wrapper things up into another higher level which can do all these different facets for us? So that we are in the business of changing the concepts, and the more mundane things get automatically generated? If the logging system knew what things were used for (or at least what the types were) then it could try to format output appropriately, which otherwise would require a human to hard-code. I guess the bottom line is that I dream of ways to be developing at higher levels of design and thought.
• 526) Maybe it is compounded by the Eclipse Jython mode, but... Jython sucks! First of all, the whole whitespace thing from Python is killing me: I keep getting errors about invalid dedents, apparently because there are some things indented with spaces and others with tabs. And I can't find where in Eclipse to turn off all tabs. Hate! Secondly, trying to call a Java method on a Java object often turns out to fail because the object has already been turned into a Jython object which obviously doesn't have the same set of methods. I've been trying to cast / convert it to a new Java object with zero luck so far. In other words, I'm wasting all this time on really stupid crap when Jython should instead be helping me get stuff done more easily. (Turns out part of the solution is to have "import java" at the top of the file, then use "foo = java.lang.String(bar)".) Talk about ass-sucking! Then, I try to use string.join( listx, '' ) and I get either "NameError: string" or "TypeError: join(): expected 1 args; got 2" heck! If I try ''.join( listx ) I get "TypeError: sequence item 2: expected string, instance of 'java.util.Arrays.ArrayList' found". Oh, and here's another kicker: Jython breaks if you try to use a StringBuffer. So, basically, Jython doesn't appear to work at all for list and string manipulation, arguably the main thing for which anybody anywhere would want to use Jython. Heck, it is even already on version 2.1, as if they didn't notice these problems through all their previous versions!
• 525) My little notes-to-self about Normal Forms in relational databases.
• 524) Scheme's syntax-case macros seemed to be the bee's knees, but it appears that there are further nuances under investigation.
• 523) LINQ is a step in the right direction, even if it isn't perfect. Methinks. Even though I haven't actually used it. At all. Ever. But I am doing silly JDO stuff these days, and also - get this - string queries in Java with no real abstraction layer (inherited code, yay) for work, and anything has got to be better than that.
• 522) On active libraries [pdf].
• 521) Conclusion? GHC is faster than Hugs [pdf].
• 520) The Mojave project would be super interesting, were I smart enough to really grok it all.
• 519) An interesting report on the kinds of threading implemented in sundry Scheme systems. It is interesting to see a slice of just how many Scheme implementations there are! Seems like you could spend your whole life working in flavours of Scheme.
• 518) Ah, a Scheme candidate for a massively multiplayer game server (like Alice (and OZ) and Erlang). Although, one might take into consideration the ability (or lack thereof) to use SMP or multi-core systems - perhaps surprisingly, many of the software systems which can handle zillions of simultaneous threads don't support more than one CPU at a time.
• 517) In particular, read how this other Spice handles multiple return values.
• 516) Possibly neat, Transmuter is aiming for the singularity. I think the idea is interesting, but the validitiy of the implementation is highly questionable; this language is designed for humans to use at least somewhat, and being so utterly dynamic means it will be, I expect, really hard to debug. I'd rather have a more static framework which then allows the whacky dynamic stuff to happen on top, with all sorts of analysis tools for both layers.
• 515) Somebody smoked a fattie and came up with more indirection than you can shake a stick at.
• 514) OK, ACL2 in DrScheme is cool. It is the kind of thing that pulls me towards a language (in this case, Scheme) in that it is a tool geared towards making things more robust.
• 513) I've always wanted units for my objects [pdf], if only through appropriate types/classes, but it can get sort of hairy and convoluted.
• 512) If you want real apps to be written, and if you aren't going to have much of any kind of static type checking by default in your language, I think you need at least some tools to do static analysis. The Dialyzer is an interesting part of the Erlang arsenal: it does all sorts of fun and helpful static checks of your Erlang code. It "has identified a significant number of software defects that have gone unnoticed after years of extensive testing."
• 511) Erlang continues to peaque my curiosity, being a static-typing bigot and all.
• 510) Sure, Perl sucks but Python is just freaking wrong.
• 509) An interesting paper [pdf] on mashing relational and applicative programming.
• 508) Another way to get functional programming in your imperative C++ world.
• 507) While concurrency with shared state is playing Russian Roulette, some day it might be a safe activity [pdf].
• 506) A little example of how to optimize Haskell code.
• 505) Ocamldefun is cool!
• 504) I think it is interesting to think about some of the reasons given for dynamic typing in Erlang with respect to interfacing disparate human organizations.
• 503) Functional languages can do ray tracing just fine... news to some, I guess.
• 502) Usenet is fun if you are looking for some material with which to kill time.
• 501) I would really like to like Clean, but it is just too scary at the moment (and it doesn't have a debugger).
• 500) Erlang is cool, and here's some recentish study [pdf] on just how cool it is. (Of course, not everybody completely agrees.)
• 499) I think people should more often choose their programming language based on what testing and debugging tools exist rather than on what buzzwords it complies with. Does it have a real, good, interactive, debugger? Are there solid unit and module test frameworks? Coverate tests? Specification checkers? (And remember, even if you use a framework for something you might want to check the checkers to reduce the chance of getting screwed by a bug in the testing framework itself. Particularly cool is Python's doctest (although it is pretty funny that anybody thinks there will be documentation, let alone documentation with valid code snippets to try). Of course, not everybody things unit tests rule.
• 498) A sad-sweet story of losing love of Lisp.
• 497) Ah, shucks, Alice ML doesn't have a debugger. Well, the 'parent' system Oz in fact does have a debugger called Ozcar, although Oz is a more dynamically typed language which I dislike. Yet I've gotta love any language that forces you to use Emacs, ha ha! (Like Epigram.)
• 496) Heck, maybe real Hungarian notation ain't so bad. Although it really begs the question, why not use a language that can find those errors automatically?
• 495) Respect history: learn about C types.
• 494) It is funny when - while discussing REST and SOAP - somebody notes that they would rewrite Jython code in Java, for speed.
• 493) Wow, Perl scares me.
• 492) A neat paper [pdf] talking about gleaning higher-level structure automatically from source programs.
• 491) Focus on version changing, types and naming in distributed computations care of the Acute project.
• 490) An open-source tool for verfication of distributed software systems: Spin. And it even has a relatively recent release, so maybe it isn't dead?
• 489) If you want to check out yet another language, Nickle sounds interesting, if not revolutionary.
• 488) Oooh! Haskell on TV!
• 487) There are several languages that target the JVM, and it begs the question, is the foundation sound since Java is bastardized?
• 486) GADTs [pdf] are the Next Hot Thing, but you can still have fun without them.
• 485) Yes, kittens, good OOP is hard. Which means we should all go and read the Scala docs ever again.
• 484) Haskell just doesn't stop being cool.
• 483) For the love of heck, please don't make me use C++ ever again.
• 482) Dr. Krishnamurthi is a real mensch. Check out (one of?) his DDJ appearance.
• 481) Everybody knows that XML sucks. An alternative (which, of course, is doomed to never have even remotely the success of XML) is SSS [pdf] which supposedly has extraced what is good about XML and left behind the badness. Yeah, well, and then it goes and has its own lameness like the fact that you are required to use upper case letters in hexadecimal digits. And the fact that keywords HAVE TO BE IN UPPER CASE. And the fact that I can't write my function_names_like_this which I have come to actually like. Now, to be fair, people probably aren't supposed to be doing lots of editing of SSS directly, it should simply be an intermediary language/format. But a specification document that says things like, "The white space doesn't mean anything, but it has to be there." does not fill me with confidence, especially because there are times when it has been useful to not have my XML files indented at all, and especially because he goes on at great length trying to nail down what the indentation rules are, including how to use tabs which, by now, everybody should know is something that should just be ignored; tabs should be allowed willy-nilly but treated as simple whitespace, as in HTML. What this all means to me is that even when somebody supposedly has learned lessons from something else, it doesn't mean they can avoid doing some real, extensive, usability testing. Humans are dumb!
• 480) RAII can be done, after a fashion, in other languages.
• 479) How depressing is it that while C# and LINQ are kinda bogus, they are actually relatively cool? What hath C/C++/Java wrought?
• 478) It is sad to read and believe that it will take ten years to get secure programming languages. You'd think that companies would have a vested interest in stopping the suck, but it turns out that maybe instead they want to have an excuse to shove 'Trusted Computing' into our orifices.
• 477) Wow, if only I understood what it all meant [pdf]. I'm not sure if that link will remain valid, here's the root.
• 476) It rings true to my ears: While the world of "little utilities" in unix has worked well for a long time, we are no longer managing linear data. Blame XML? Well, not really, since we were dealing with multi-line records before then - that is why Perl became so popular, because it gave more stateful power to syntax people already knew. So maybe we really do need things like scheme on the stdio?
• 475) There seem to be almost as many scheme interpreters as there are tutorials on monads. What does it all mean?
• 474) A next big thing: type refinement.
• 473) A cute story espousing this power that is GNU AWK.
• 472) I think there's probably a simple idea here, but I haven't seen the light yet - but, apparently, it is more proof that Haskell is cool.
• 471) Forth is great and all, but it sounds like fool's gold.
• 470) For those Haskell hippies out there who envy JML, check out HasCASL. Word.
• 469) So I don't have to keep re-reading the PDF, "The discussion above suggests that developers should avoid calling public methods on the current object this. If a public method contains code that can be reused elsewhere in the class, the code should be encapsulated in a protected or private method, and the public method should call that internal method. This guideline was previously suggested by Ruby and Leavens, and appears to be common practice within the Java standard library in any case. For example, the java.util.Vector class in the JDK 1.4.2 internally calls a protected method, ensureCapacityHelper, to verify that the underlying array is large enough - even though the public method ensureCapacity could be used instead."   "Protected methods should be final if they don't represent an explicit extension point for subclasses. The author of a library should carefully document under which circumstances non-final protectedmethods are called, so that subclasses can rely on the semantics."
• 468) No really, this time monads will make sense. Also, this note at LtU. Maybe.
• 467) While TOM is dead, the author says, "Focusing on the run-time flexibility, Common Lisp would undoubtebly be comparable. Focusing on compile-time flexibility, aspect oriented programming might give the right angle." Interesting to read his take on the flexibility of programming languages.
• 466) If you are curious about Scala's various and sundry building blocks (traits, views, mixins, etc.) then Scalable Component Abstractions [pdf], might edify.
• 465) New and oh-so-exciting, the Scala Wiki.
• 464) It had to happen: a package for writing Erlang in Haskell.
• 463) The Jekyll language is like a Haskellized alternative to C++. Sorta neat!
• 462) Is nobody else angry that Lisp is now successful, but it is owned by Microsoft? Oh, the humanity!
• 461) Some nice papers on datatype-generic programming (see the various "Scrap Your Boilerplate" links [1] [2], and the links to work by Jeremy Gibbons in that lab, below.)
• 460) Note to self: study up on you got your call-by-value in my call-by-name work.
• 459) Food for thought: programming viewed from a thermodynamics perspective.
• 458) If programming can be a craft or an art, then why are we still using crappy editors? Why can't we paint our code? :-)
• 457) If you can grok what it is going on about, PiDuce might be nifty for XML stuff like web services.
• 456) Abstract of some thoughts on programming languages for video games [acm], in POPL '06. The slides are available [ppt].
• 455) If, for some strange reason, you actually like REBOL, then you might be interested in some similar alternatives (especially those that aren't closed source).
• 454) Judging from the web site design, I'd think Internet Business Logic was some nut-job vaporware, but I've heard there might actually be something more to it.
• 453) Nice to know that people still get confused by the term 'functional language' [pdf].
• 452) Planet Erlang has lots of really tasty links on concurrency and multi-processor issues. Apparently, the upcoming release of Erlang/OTP will support SMP.
• 451) How to make your parallel, distributed, message passing system more efficient, through examination of the object identity crisis! It is a neat read because one might find oneself nodding vigorously in agreement when they mention of crappy and subtly complex the notion of 'equals' is in many languages. (I mean, how long did it take in the Java world before people figured out how to really implement Objects?)
• 450) A plethora of tutorials from Lecture Notes in Computer Science.
• 449) Concurrent Haskell gets a debugger [pdf] of sorts, and some notes about better communication abstractions [pdf].
• 448) Reactive systems may mean different things to different people. I've seen reactive programming in ML [pdf], which led me to Esterel and its ilk. In the functional programming realm, too bad Timber appears dead. Eden had a "wrap up" publication in 2005. So maybe that all means I'd choose to implement reactive features in Alice ML some day? DbHas and Ptolemy SR [pdf] are worth investigating. Signal [pdf] and Lustre are declarative rather than Esterel's imperative style, at least. It appears that Lustre has even gone commercial. If you like O'Caml then check out Lucid Synchrone. Here's another overview of the field.
• 447) The swiss army knife that is superfold/CFoldLeft.
• 446) If you feel like it, you can write an entire OS [pdf] in Modula-4, er, I mean Oberon. Apparently Bluebottle is the spiritual successor.
• 445) A very nice and very basic intro to ML, which is useful as a refresher. It even has some fun multiple choice quizzes. Unfortunately, it also reminds me that ML does have some blatant uglyness to it: ~ is used to make negative numbers.
• 444) Kamaelia has a nice cat logo, at least.
• 443) It is always fun to learn a new language, like Python, and see all the places they screwed up.
• 442) I was all excited about using Jython but then I hit stuff like this which is apparently still broken nigh 3 years later!? Then, just try to find the sources for Jython! It is completely obfuscated how one might get them. It turns out the class file you download for installing is an installer app that contains the sources and can install them for you. Ah. (And it installs things in a rather non-standard place in Windows, for crying out loud.)
• 441) Curse XML [pdf], or do not, it does not matter.
• 440) Kevin Greer's notes on context lead to some interesting things, including a little ditty on acquisition.
• 439) A co-worker pointed out that while neither Python nor Perl are so beautiful you'd want to marry them, nevertheless one should probably prefer Python for long term maintainability. I think I can agree with that, even though I don't know Python well at all - so time to start learning it. There are some interesting libraries in the Cheese Shop: Erlang-style concurrency, Lindenmayer systems, Quixote web apps, Skunkweb web apps, Snakelets web apps, a media catalog system, web app environment abstractions, Webware web apps, Albatross web apps, Aquarium web apps, JOTWeb web apps, Webunit web testing and a link checker to name just a few. (I find it curious that there are so many web app systems - I doubt that they are all particularly good, particularly the ones that claim to be reinventing JSP/Servlets, but they might still be food for thought.)
• 438) Some thoughts on why you shouldn't invent another XML-based language.
• 437) It amuses me that humans can come up with something supposedly simple, like object oriented approaches to software, only to find themselves in something of a morass of details and choice.
• 436) An interesting look into the reasoning behind the Java API Design Guidelines.
• 435) A little course on design by contract.
• 434) Some day I'll learn up on all the really cool scientific / mathematical languages out there.
• 433) I don't understand a word of it yet, but Fresh Caml sounds like it could teach me a thing or two. Likewise the later project Acute, for distributed computation.
• 432) Remind me to get on the JML bandwagon.
• 431) Some rainy day I'll read up on Effects Systems [pdf].
• 430) Learn a little bit about all those langauges, care of Paul Graham.
• 429) Super Collider does seem to live up to its name, what with lexical and dynamic scoping available, etc.
• 428) Yet another example of mind-bending [pdf] that can be done with glorious Haskell.
• 427) The Scala community is getting some more goodies: coursework with sample code, and a whacky package universe.
• 426) Stream-based processing is interesting; check out things like OmniMark, StreamBase and KDB, or just stream processing in general.
• 425) Put Lua in your O'Caml pipe and smoke it.
• 424) Learn up on continuations, fun for the whole family.
• 423) Learn up on metaclass programming
• 422) Funny, I think the Space Shuttle uses [pdf] will nevertheless be of some help.
best 2 out of 3 [pdf] computer votes.
• 421) Flow based programming looks interesting, and I guess the style appears in Java 5's concurrency, in Oz, and in Alice?
• 420) Turns out, if you grok unix pipes, you are on your way to grokking monads. Sorta. It is all so clear to me now!
• 419) The folks at Motion Twin have some interesting language developments in the web/game arena.
• 418) While not solving all the religious wars, maybe cleaning up exception syntax [pdf] will nevertheless be of some help.
• 417) I scream, you scream, we all scream for Smalltalk.
• 416) If I had a penny for every document purporting to explain monads [pdf], even restricting to those documents that target Haskell, I could at least get myself a cup of coffee. Look, here's yet another! Don't forget the newsgroups! Another. Another [pdf].
• 415) Go freak yourself with Smalltalk MetaClasses [pdf].
• 414) I'm going through the Alice ML intro docs, and while the 'future' thing is neat, I'm a little stressed out about the fact that there is the side effect of forcing evaluation of lazy values that only some things have, and there's nothing to indicate which do and do not; you just have to know. That doesn't seem particularly clean to me. Some misc other things: notes on promises, futures, etc.. The somewhat infamous translated CTM examples.
• 413) People say they would rather get an empty iterator than a null one, so they don't have to do if( iter != null) checks everywhere. But I think the right fix would be to have a way of writing a simpler-and-better if, rather than hacking things by creating empty iterators. Is that pedantic? Or just dumb?
• 412) The JSF stuff might turn out to be neat; making server-side Java less utterly convoluted and evil?
• 411) Heck, you can do just about anything in Haskell once somebody figures it out, from nigh-dependent typing to polyvariadic functions.
• 412) An update on how to scrap your boilerplate [pdf].
• 410) I heartily concurr with these thoughts, especially that the underlying source code must fit into regular ASCII files, and that it must interface to C. I'd further add that it must have a debugger.
• 409) Another list of papers for rainy days.
• 408) For those disbelievers out there: a Quake-like FPS, written in Haskell. The thesis [pdf] gives gory implementation details, w00t!
• 407) I like the idea of advanced languages like Lisp, Haskell Scala, et. al. However, I have to say that they terrify me because I just know that at some point there will be a compiler bug, or I'll have to use somebody else's code, and my little 10% understanding of the language, let alone the underlying implementation, will prevent me from being able to make any head-way. At least with C and simple C++ you have more of a snowball's chance in hell of following everything from top to bottom to get to the root of the problem.
• 406) I guess everybody should read End-to-End Arguments in System Design.
• 405) Learn how fold and unfold should be your friends [pdf], while maintaining efficiency.
• 404) While the capitalization rules could use some work, PLaSM looks kinda neat.
• 403) I think Bertrand Meyer's talk about design by contract is pretty right-on. Ditto when he notes that usability should matter to programmers. If you don't already know how to write contracts then maybe you aren't a good software engineer. (I used to know and do it with the Z language, but haven't had the excuse to do it at any job!)
• 402) Heck, you can do anything you want in C++... as long as you are willing to augment it [pdf].
• 401) Bertand Meyer selling Eiffel by way of discussing Software Quality. His explanation of exception handling in Eiffel is interesting; I think nobody has a good answer for what exception handling really should be. See, if it is for really exceptional things then by definition you can't handle it well. If, on the other hand, you think you could handle it, then maybe the code which deals with it shouldn't be in the exception side of things, but in the regular code with return value checking?
• 400) Programming languages are simply too complex. Where are the Star Trek UIs that ask a few poignant questions and then do all the programming for us?
• 399) Sometimes, simple ideas work out really well.
• 398) Boo has a few pre-1.0 releases under its belt, so maybe I can start taking a look at it. (I must say, I'm tired of looking at nifty new languages that blow chunks on (literally!) "hello world".)
• 397) Some possibly thought-provoking "Recommendations" (scroll down) regarding how to build modular architectures. It is nice, but on the other hand it kills me that human beings are still worrying about nuances like this. It should all have been pretty much already codified as best practices and put into a good knowledge base system that works with the IDE to make everything magically easy. (Even though that is Star Trek stuff.)
• 396) A classic dilemma in software: how do you balance openness vs. closedness? Why don't our systems help us resolve these issues more robustly? We should be allowed to have things be closed, yet not lose the ability to extend, and we should simultaneously have things open, yet have guarantees that we won't lose security and stability.
• 395) I need to sit down and write a tutorial concisely explaining all the different ways to do functionality injection (or find one somebody else has done already). Same thing goes for just about any choices one faces: do you use a macro, an anonymous function, a callback, a continuation, or something else? Do you use a single threaded event loop, or asychronous threading? Do you want a desert topping or a floor wax?
• 394) Per Bruce's little note, I would love a chart that breaks down the various flavours of generics so I can grok what on earth is going on in all the different languages.
• 393) I think Bruce Eckel is a real mensch, for you Java 5 kids.
• 392) People bemoan how functional languages don't get any respect or use in industry. One common reason people give is that functional languages tend to require a tad more thought than your run-of-the-mill Java pre-5. Now that Java 5 is out, I wonder if the same doom will happen there? Will Java will become asymptotically close to C++ over time?
• 391) Niklaus Wirth lives on in open source.
• 390) Another language for writing video games might be BitC which mixes Scheme, ML and C all together - if you can believe it!
• 389) A little tour of GADTs in OO, [pdf] rather than the usual functional suspects.
• 388) Making threads even smaller, and making an operating system on top.
• 387) Putting software developers out of work, one algorithm at a time.
• 386) Fun with visualizing source code (or whatever).
• 385) For just about any programming language, here's how to implement monads. And, some even more monadic treatment for Java.
• 384) Hoogle's API search may provide helpful during your late night Haskell hacking.
• 383) If you found monads easy and boring, here's another categorical thing [pdf] to put in your programmng pipe and smoke.
• 382) I think these are some smart folks.
• 381) What would you want for building robust systems?
• 380) Face it, distributed computing is hard.
• 379) Blow yoru mind with Aldor, which purports to mix up functional, OO and AO styles nicely.
• 378) Have fun with Logo, why don't you?
• 377) Interval computing sounds neat, in that it is trying to fix something everybody thought was OK but was actually really, really broken. Falls into the reliable computing category.
• 376) These lecture notes from Dr. Felleisen appear interesting.
• 375) Some help for learning up on Scala.
• 374) In the world of the Web, haXe looks pretty interesting. Well, except for the fact that he makes Integer inherit from Float! D'oh!
• 373) Here's hoping we get some hot intentional style computing action from the domain/j stuff.
• 372) All I'm saying is, transactions are hard.
• 371) Check out the HiveMind project, which is sorta dependency injection++.
• 370) Here's what seems to me to be a delicious example of why nobody really understands inheritance. Stupid Java.
• 369) I don't get it. Why not just use a language that actuall has typing? (I know, I know.) Actually, on the whole, I'm not really liking multimethods along the lines of some implementations (see Dylan) with a magic re-dispatching step; I would much rather have it made explicit in the 'wrapper' method.
• 368) What form of vaguely Hungarian notation do you use?
• 367) Having used C++ to limited degrees myself, I conclude that C++ programmers should get psychological help to quit the addition.
• 366) If you go for some whacky multi-threaded app, check out TCMalloc from Google, the older Hoard, or the commercial and venerable SmartHeap.
• 365) While I'm sure monads are great, and everything, one might do well to be wary of getting too carried away with them when a more 'purely' functional approach is available.
• 364) Lean about metamorphic programming (in Haskell).
• 363) I don't like case insensitive languages. I also don't like the chance of having Foo and foo get confused and lead to bugs in a case sensitive language. Thus, we do what CORBA did: have it be case sensitive, but explicitly disallow another name that differs only in case. (Or like NTFS, or the Amiga DOS FS?) Interesting how Unicode throws in a monkey wrench, as does any desire to easily use notation from math/physics. Perhaps the language can generate warnings for possible collisions? Perhaps there could be explicit modes for sensitivity vs. not (a type from which one could inherit)? Hm.
• 362) We are drowning in APIs, so I think this navigator has merit. (Philip Greenspun noted that anybody in his class who used Java would invariably have to give up and drop out, because they could never get over the hump of choosing which libraries to use for any given sub task! I dare say, some languages are just not designed for use in rapid prototyping.)
• 361) The BON method looks to be a possibly interesting OO analysis tool. Also, check out Fundamental Modeling Concepts.
• 360) If you are confused about JMS vs. JINI vs. JavaSpaces vs. whatever, this thread might shed some useful light. Although they don't mention JXTA, XMPP, Cactus, Globus, etc. ad infinitum. And how does this relate to Erlang?
• 359) Face it: programming is hard. But, you'd think there would be some semantics, somewhere, that would clean up this type of poop?!
• 358) Some people, when faced with a problem, say, "I know! I'll use UML!" Now they have two problems.
• 357) I really dislike all the possible combinations of public, private, etc. that some languages let you do. On the other hand, it seems like we do need some expressivity there, more than what Java supports, for example.