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!).
Whining Ensues
- 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.