Comments on: Programming Languages are PC OSs circa 1986 http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/ programming, politics, & other religious issues Wed, 08 Feb 2012 14:16:00 +0000 hourly 1 By: nickik@gmx.ch http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/#comment-37505 nickik@gmx.ch Tue, 13 Apr 2010 23:07:13 +0000 http://enfranchisedmind.com/blog/?p=786#comment-37505 Hallo, I'm not an expert on so many langauges so I don't want to spread the liddle stuff I know. One thing I want do mention about error handling. I'm learning Dylan at the moment and I really like the language. You guy's sould really take a look at the error handling system in dylan. I have never seen it done in a cooler way but I only know a couple other languages. Dylan was designd for big applications so it wanted it to make errorhandling right. What do you think. <a href="http://www.opendylan.org/books/drm/Conditions" rel="nofollow"> Dylan Conditions </a> or here </a> Hallo,

I’m not an expert on so many langauges so I don’t want to spread the liddle stuff I know.

One thing I want do mention about error handling. I’m learning Dylan at the moment and I really like the language. You guy’s sould really take a look at the error handling system in dylan. I have never seen it done in a cooler way but I only know a couple other languages.

Dylan was designd for big applications so it wanted it to make errorhandling right. What do you think.
Dylan Conditions or here

]]> By: Marc Stock http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/#comment-33767 Marc Stock Wed, 01 Oct 2008 15:35:04 +0000 http://enfranchisedmind.com/blog/?p=786#comment-33767 "DSLs exist in their own driving context, which should eliminate the surprises." To a point, but it doesn't fix the problem because when you're applying an operator to something, you should know the context as well. I don't think context is the big issue here. It's interpretation of how said operator should function given that context. Depending on how you design a DSL, it could be subject to many questions of this nature (which is why a lot of people are saying you shouldn't make a DSL very natural language-like). “DSLs exist in their own driving context, which should eliminate the surprises.”

To a point, but it doesn’t fix the problem because when you’re applying an operator to something, you should know the context as well. I don’t think context is the big issue here. It’s interpretation of how said operator should function given that context. Depending on how you design a DSL, it could be subject to many questions of this nature (which is why a lot of people are saying you shouldn’t make a DSL very natural language-like).

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/#comment-33766 Robert Fischer Wed, 01 Oct 2008 15:23:23 +0000 http://enfranchisedmind.com/blog/?p=786#comment-33766 The problem with operator overloading is mixing and matching contexts -- what "+" means in one place vs. another is context-driven, and so mismatched contexts can cause surprising results. DSLs exist in their own driving context, which should eliminate the surprises. The problem with operator overloading is mixing and matching contexts — what “+” means in one place vs. another is context-driven, and so mismatched contexts can cause surprising results. DSLs exist in their own driving context, which should eliminate the surprises.

]]> By: Marc Stock http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/#comment-33765 Marc Stock Wed, 01 Oct 2008 15:10:29 +0000 http://enfranchisedmind.com/blog/?p=786#comment-33765 I used to do C++ programming many years ago. Back then, operator overloading was generally frowned upon because the C++ world went through an era where it was heavily overused (new toy!) and even in cases where it was appropriate, the effects of the overloading were often not what was expected. Method names that clearly indicated the function to be performed became far more preferred. The '+' symbol can mean different things to different people. Add to this the fact that (at least at that time -- I don't know if it's changed) IDEs didn't have javadoc like support for operators and it just wasn't pretty. Operator overloading is great when it's very clear what the operator should be doing given the context but outside of basic math, those opportunities are rare. That said, using operator overloading can be thought of as sort of a DSL Lite and if the developer community cannot handle that, can it really handle full blown DSLs? I used to do C++ programming many years ago. Back then, operator overloading was generally frowned upon because the C++ world went through an era where it was heavily overused (new toy!) and even in cases where it was appropriate, the effects of the overloading were often not what was expected. Method names that clearly indicated the function to be performed became far more preferred. The ‘+’ symbol can mean different things to different people. Add to this the fact that (at least at that time — I don’t know if it’s changed) IDEs didn’t have javadoc like support for operators and it just wasn’t pretty. Operator overloading is great when it’s very clear what the operator should be doing given the context but outside of basic math, those opportunities are rare. That said, using operator overloading can be thought of as sort of a DSL Lite and if the developer community cannot handle that, can it really handle full blown DSLs?

]]> By: Robert Fischer http://enfranchisedmind.com/blog/posts/programming-languages-are-pc-oss-circa-1986/#comment-33764 Robert Fischer Tue, 30 Sep 2008 15:47:25 +0000 http://enfranchisedmind.com/blog/?p=786#comment-33764 @Scott Vokes The syntactic sugar that Java did -- basically proving some low-level operator overloading for integer and floating point arithmetic -- seemed to be a nice compromise between general-case operator overloading (evil[1]) and universal operational purity (off-putting). Surprisingly, I've heard very few people lamenting the inability to define + for matrices in Java. The one downside is that there comes a point in every journeyman Java developer's life where they get confused about why 1 / 7.0 * 7 > 1 -- the reality is that floating point and integer arithmetic are fundamentally different, so mixing the two is a Devil's bargain: you don't put off beginners used to blurring those boundaries, but you put off intermediate developers who suddenly discovered that there's a lot of dangerous plays. Of course, by the time they're intermediate developers, you've already suckered them into knowing your language pretty well, so they're vested. [1] The biggest evil of general-case operator overloading is that changing <code>foo + bar</code> to <code>bar + foo</code> suddenly drastically changes the definition of "<code>+</code>". It gets even worse when you consider <code>foo * (bar + baz)</code> vs. <code>foo * bar + foo * baz</code>. Or, y'know, <code>1 / 7.0 * 7</code> vs. <code>7 * 1 / 7.0</code>. @Scott Vokes

The syntactic sugar that Java did — basically proving some low-level operator overloading for integer and floating point arithmetic — seemed to be a nice compromise between general-case operator overloading (evil[1]) and universal operational purity (off-putting). Surprisingly, I’ve heard very few people lamenting the inability to define + for matrices in Java. The one downside is that there comes a point in every journeyman Java developer’s life where they get confused about why 1 / 7.0 * 7 > 1 — the reality is that floating point and integer arithmetic are fundamentally different, so mixing the two is a Devil’s bargain: you don’t put off beginners used to blurring those boundaries, but you put off intermediate developers who suddenly discovered that there’s a lot of dangerous plays. Of course, by the time they’re intermediate developers, you’ve already suckered them into knowing your language pretty well, so they’re vested.

[1] The biggest evil of general-case operator overloading is that changing foo + bar to bar + foo suddenly drastically changes the definition of “+“. It gets even worse when you consider foo * (bar + baz) vs. foo * bar + foo * baz. Or, y’know, 1 / 7.0 * 7 vs. 7 * 1 / 7.0.

]]>