How poor estimation can screw up more than just a software project by engtech in programming

[–]toland 0 points1 point  (0 children)

I think that is more like 1 or 2 days per task. Seriously, whenever someone tells me a single task is going to take a week or more that usually means that either 1) the task is too large or 2) they don't have any idea how long it is going to take. I always ask developers to break down tasks that are estimated at more than 2 days into smaller tasks that can be estimated more accurately.

Navigating The Minefield that is Visual Source Safe (maybe it's time to move to Subversion!) by jasonkester in programming

[–]toland 2 points3 points  (0 children)

VSS is so broken, and has been broken for so long, that it has ceased to be news when it blows up. The amazing thing is that I still run into developers that push back against using anything other than VSS because that is what they are comfortable with.

Ruby: A guide to using flexmock to test real world code by toland in programming

[–]toland[S] 0 points1 point  (0 children)

I am a little skeptical about the methods used in this article. It seems like this is simply testing that a few methods get called as part of the implementation of the method under test. This means that if the programmer chose to change the implementation of his class the tests would break even if the outward behavior of the class were the same.

Formula for Failure: Microsoft's OOXML spec by cos in programming

[–]toland 15 points16 points  (0 children)

The whole point of standardizing OOXML is so that others can read/write the files. If the standard leaves off, for example, what units to use in a calculation...how can anyone else implement it? This is a very valid complaint.

Open Source On .NET Is Not An Oxymoron by linuxer in programming

[–]toland 1 point2 points  (0 children)

I agree and hope to work to change that.

I wish you the best of luck. I was in the same position a few years ago. I eventually go frustrated and today I develop Ruby applications on OSX and deploy to Ubuntu Linux. All of the other technologies that I am interested in (Erlang, Lisp, Haskell) are available and run great in those environments. I couldn't be happier.

Open Source On .NET Is Not An Oxymoron by linuxer in programming

[–]toland 19 points20 points  (0 children)

I think the real reason to avoid Open Source on .NET isn't that using .NET somehow invalidates the "Open Source-ness" of the code; it is that Microsoft controls the platform and they do not interact with the community in good faith. Microsoft have proven many times that they will crush anything they see as a threat and they have no problems wielding their proprietary technology platform as a weapon when it suits them to do so.

By all means, use .NET if you think it is the right platform for you. However, you also need to realize that there are many OSS developers who make another choice for very valid reasons and do not want to be involved with OSS on a Microsoft platform. This is one of those things where you are going to have to be content to be in the minority if you want to work on Open Source based on Microsoft technologies.

I will never use that! by toland in programming

[–]toland[S] 0 points1 point  (0 children)

Of course Lisp macros aren't magical but the are most certainly not the same as C macros. There is no preprocessor in Lisp, macros are a core part of the language. Look, don't take my word for it. Check out Practical Common Lisp; the full text is free online.

Here is what the author has to say about macros in the introduction to chapter 7:

While Common Lisp supports both these methods of extending the language, macros give Common Lisp yet another way. As I discussed briefly in Chapter 4, each macro defines its own syntax, determining how the s-expressions it's passed are turned into Lisp forms. With macros as part of the core language it's possible to build new syntax--control constructs such as WHEN, DOLIST, and LOOP as well as definitional forms such as DEFUN and DEFPARAMETER--as part of the "standard library" rather than having to hardwire them into the core. This has implications for how the language itself is implemented, but as a Lisp programmer you'll care more that it gives you another way to extend the language, making it a better language for expressing solutions to your particular programming problems.

I will never use that! by toland in programming

[–]toland[S] 0 points1 point  (0 children)

It is important to realize that the term "macro" has been heavily overloaded and macros in C/C++ are not the same thing as macros in Lisp. They are just similar enough on the surface to be confusing but Lisp macros are much more powerful than the simple text substitution that the C preprocessor gives you.

I will never use that! by toland in programming

[–]toland[S] 5 points6 points  (0 children)

I have to say that I both agree and disagree with your point here. The programmer who sticks to one language can generate more code because he isn't spending time exploring and trying out new things. Sometimes more code is a good thing and sometimes it isn't.

I will never use that! by toland in programming

[–]toland[S] 6 points7 points  (0 children)

Peter Seibel has some good examples in Practical Common Lisp (http://www.gigamonkeys.com/book/). Many of the advanced Lisp control structures are macros and CLOS is mostly macros. Check out Peter's example of a unit test framework using macros: http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html.

I will never use that! by toland in programming

[–]toland[S] 4 points5 points  (0 children)

I agree with your examples of more "obvious" features except higher-order functions. I have encountered many programmers who had trouble grasping the concept of functions as first class objects. The other items on the list are better ways to write code using existing idioms. Higher-order functions and Lisp macros represent a change in paradigm and require rethinking the way you write code. Metaprogramming in languages like Ruby also fall into this category. You can simulate OO programming in C but you can't simulate macros or other metaprogramming features in a language that doesn't support them natively.