Home
FAQ
Feedback
Departments
Discussions
(new topic)
Language Evaluation
PL Courses
Research Papers
Design Docs
Quotations
Genealogical Diagrams
|
|
|
|
critiques
| Software Fault Prevention by Language Choice |
|
Software Fault Prevention by Language Choice:Why C is Not My Favorite Language. Richard Fateman.
This paper was mentioned in the discussion following the Kuro5hin article Why C Is Not My Favourite Programming Language which everyone seems to be discussing at the moment. Nothing particularly new in that article, but since it is aimed at working programmers, it may have a bit more success than more in depth critiques of C.
Fateman's paper contrasts C with Lisp, making it quite amusing. Had I written it I would have chosen Ada instead of Lisp, seeing as the paper doesn't try to attack the imperative paradigm, merely C, once the standard bearer. Seeing its offsprings, you start to develop fond memories of C, but I'll save that for another time...
Posted to critiques by Ehud Lamm on 2/10/04; 2:17:17 AM
Discuss (8 responses)
|
|
| The Sound of Lost Productivity |
|
James Robertson, in his Cincom Smalltalk blog, writes...
[Even] though most of the learning is at the library level - the language and runtime still matter. In Smalltalk, one can extend or change any class or method you need to change. That's highly useful - because the library designers don't always make it easy to replace a given class via subclassing. Sometimes, you just have to go in and modify the base system (or build scads of wrapper classes). In BottomFeeder, I have had to both subclass and modify the base XML parser - in order to handle errors in ways that the original developer simply did not foresee.
It's a nice theory to say that the library can be fixed, or that an unchangable library is a boon - but that sound you hear is the sound of lost productivity.
Smalltalk systems typically have good version control, comparison tools, packaging tools, and browsers. An application in Smalltalk very often will add a instance methods in the Object class, and other so classes that come with the core system. These are only included in that application.
This is very hard to duplicate in languages like Java and C#, where you pretty much have to take what you can get from the vendor. Maybe "aspects" or some other mechanism can get around these core limitations to developer productivity. Doubtless not with the same ease and manageability.
Posted to critiques by Patrick Logan on 12/16/03; 5:47:45 PM
Discuss (2 responses)
|
|
| Over and Under in a Box |
|
Don Park writes about Java and dotnet, presumably C# and VB.Net...
I have examined quite a number of open source Java and .NET projects recently and there is a striking contrast between the two groups which is that Java projects tend to be over-architected and .NET projects tends to be under-architected...
There is also a disturbing trend of hiding or scattering information from developers so that it is difficult to sit down and review several pages of code without having to run around looking for the hidden pieces...
After a few sessions of trying to get some decent performance out of .NET, I am already starting to see boxes in my sleep.
Posted to critiques by Patrick Logan on 12/15/03; 10:38:09 PM
Discuss (2 responses)
|
|
| Moving Away From XSLT |
|
Martin Fowler explains how he is moving away from XSLT as the transformation language for his web site.
All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I've even written a whole book that way.
For most of this time I've used XSLT as my transformation language. I've got pretty good with slinging XSLT around and getting it to do what I want.
But no more.
When I wrote the software for this Bliki (on a long flight) I did it in Ruby.Prior to that I used Ruby to do a new version of my home page. My conclusion from this exercise was that using Ruby for XML transforms was much easier than using XSLT.
Posted to critiques by Patrick Logan on 9/22/03; 6:26:58 PM
Discuss (19 responses)
|
|
| Are delegates the moniker of .NET? |
|
Don Box reveals a preference for FP over OOP without even realizing it (or at least not explicitly stating it):
... the use (or lack of use) of delegates can capture a developer's intention with more precision than would be possible in a simple class/interface world.
For me, the most important aspect of delegates is they tend to result in more loosely-coupled designs than one gets with traditional class/interface-based approaches. Specifically, when you expose an extensibility or integration point as a delegate, you are effectively saying that the contract between your code and the outside world is implicit rather than explicit.
Given that delegates are just the .NET way of expressing function references (with semi closures) as first class citizens, Don is basically demonstrating some advantages of higher order programming.
BTW, monikers are a COM mechanism for identifying object instances (and more) using a human-readable name (with other amenities such as name composition).
Posted to critiques by Dan Shappir on 7/22/03; 1:53:25 AM
Discuss (21 responses)
|
|
| With |
|
I introduced "With" to VBA because Excel macros were full of cases where you did ten things to the same cell, range, chart, etc. For example if you have a macro that creates a chart, you need to set about 23 options on the chart before it looks the way you like it. In the user interface, you select the chart and do 23 things. This maps nicely to opening a with block and doing 23 things, so the macro recorder could generate with blocks and thus create vastly cleaner code. (Try it... the macro recorder generates With blocks all the time).
A discussion of the With statement in the context of the various PLs that implement it, and those that do not. Includes comments from Joel Spolsky himself, who apparently introduced this facility to VBA.
Posted to critiques by Dan Shappir on 6/12/03; 2:23:24 PM
Discuss (9 responses)
|
|
| Shrink-wrap developers: what programming language? |
|
I'm a shrink wrap programmer ... our 16 programs were writtin in vb 3 and it's time for a rewrite ... WHAT LANUAGES ARE OTHER SHRINK WRAP DEVELOPERS USING?
This is a question I've thought about for some time. As R&D Manager for my company I can determine (or at least influence ;-) the PLs used for developing new projects. For server-side apps its mostly a question of target platforms, ease of development and scalability requirements. This is because issues like ease of installation, and hardware and software requirements are often secondary.
With shrink wrap software the situation is very different. We need to support some old systems (think Windows 95 no service packs) and installation must be as simple as possible (so installing VMs and stuff can be a problem). If the software can be downloaded from the web (which in our case often happens) download size can also be very important.
Given all this, do I really have a choice other than C/C++, VB and Delphi?
Posted to critiques by Dan Shappir on 6/2/03; 1:09:44 AM
Discuss (21 responses)
|
|
| What I Hate About Your Programming Language |
|
(from the LtU discussion group)
Matthew Markland points to an article on Oreilly's OnLamp site where chromatic discusses his likes, but mostly his dislikes, of various programming languages.
... looking at the popular languages for open source development today, there are many syntactic and otherwise superficial differences. At one level, all languages have a philosophical axe to grind. They exist for a reason. At another level, they're all just flipping bits and jumping around in a long chain of ones and zeroes. Everything in between is a matter of taste, and that's where most of the messy details go.
Posted to critiques by Dan Shappir on 5/13/03; 11:45:39 PM
Discuss (12 responses)
|
|
| Tools for the short hike |
|
Via Slashdot
... there is a level of quiet discomfort between the "scripting" versus "programming" factions in some corporate development environments in which I have participated. In some instances, executive-level technology management has held scripting languages in disdain as not being "real" languages for day-to-day problem solving, which has discouraged highly talented scripters on staff from practicing their craft.
Chad Dickerson seems to make the distinction between "scripters" and "programmers" solely on the basis of language used (programmers = C++, Java ; scripters = Perl, Python). For me, any real distinction can only based on formal training (which could be obtained by autodidaction). A programmer is someone how understands some basic tenants of program design, while a scripter (if you use the derogatory aspect of the term) is someone who just hacks out code.
Given this definition, I would certainly favor a programmer over a scripter, no mater which language either of them used.
Posted to critiques by Dan Shappir on 2/26/03; 12:35:54 AM
Discuss (17 responses)
|
|
| MSDN: C# and Java - Comparing Programming Languages |
|
A detailed and useful analysis of both languages.
The first part of this article that talks about the similarities between the two languages is much more interesting than the detailed comparison that follows.
LtU readers will know that my opinions on genericity are very different than the author's. Luckily the designers and users of both languages agree with me, and genericity will be added to both languages (I am not sure really whether I should use the future tense here).
Posted to critiques by Ehud Lamm on 1/25/03; 11:50:38 AM
Discuss (4 responses)
|
|
| Critique of the Windows API |
|
Diomidis Spinellis. A critique of the Windows application programming interface. Computer Standards & Interfaces, 20:1-8, November 1998.
This is not a language critique, but many of the issues raised are programming language dependent.
I always said Windows is a programmer hostile environment; this paper gives ample evidence in support of this conclusion.
To quote Petzold, In a sense, the whole history of new programming languages and class libraries for Windows has involved the struggle to reduce the windows hello-world program down to something small, sleek, and elegant. (Programming Microsoft Windows with C#, Microsoft Press, 2002, p. 47).
Posted to critiques by Ehud Lamm on 8/29/02; 3:06:59 PM
Discuss (2 responses)
|
|
| Is EJB Always Necessary? |
|
If your application doesn't involve a lot of true distributed computing or require distributed transaction management, the odds are very good that there's a better way to do it.
And more along these lines in a response to the original article.
I like the notion of distributed objects that mask deployment details. To make this happen, these distributed objects must be first-class and light weight.
Posted to critiques by Ehud Lamm on 8/22/02; 9:19:11 AM
Discuss (2 responses)
|
|
| XLANG and WSFL: Syntactic Arsenic |
|
(via Patrick Logan's Weblog)
It seems that the world has gone XML crazy lately. Because of the hype, its not surprising that anything that can be, has been turned into XML. Still, XML is lousy to read and write. Programming language people have a term for making the syntax of a language pretty: syntactic sugar. XML is syntactic arsenic.
A rather exasperated commentary on where XML ought and ought-not be used.
Posted to critiques by Dan Shappir on 7/18/02; 6:14:45 AM
Discuss (9 responses)
|
|
| C and C++: A Case for Compatibility |
|
I believe it is in the long-term best interest of the C/C++ community to remove all incompatibilities between C and C++. We ought to try for that. Clearly, removing incompatibilities would involve changes to both languages and compromises would have to be crafted to minimize the impact on users of both languages. Silent changes - that is, changes that are not easily diagnosed by a compiler - should be minimized. Wherever possible, the compromises should be crafted to increase the consistency of the resulting set of features and to simplify the language rules. It will be difficult to remove all incompatibilities. However, the amount of work required from the C/C++ community to reach compatibility will be far less than that required from it to live with increasingly incompatible languages.
The second part of Bjarne Stroustrup's three-part discussion of the future of C and C++ (the first part can be found here). Bjarne makes the case for improving compatibility between C and C++, even when it involves changes to both languages.
Posted to critiques by Dan Shappir on 7/17/02; 7:43:31 AM
Discuss (1 response)
|
|
| Animism: An Essential Concept in Programming? |
|
Animism is the attribution of the qualities of living things to inanimate objects. Animism often occurs in primitive religions, where everything (the ground, the sky etc.) is considered to be alive and interacting with these beings is an essential part of religious ceremonies. (That's my take on animism. I'm not an anthropologist or a theologist so standard disclaimers apply.) Intellectually we've out grown animism. Or have we? The author argues:
"Animacy is a powerful conceptual tool with which to analyze
programming paradigms (see Table 3.2 for a summary). In particular, it can help explain the specific appeal and utility of object-oriented programming, which has in recent years become an extremely popular model for commercial programming. OOP is fundamentally just a way of organizing a program, and it has not always been clear why or even if it is a superior way to do so. Animism provides a theory about why OOP is powerful: its particular style of modularization divides up a program so that animate thinking can be readily applied to any of its parts. Functional programming, on the other hand, provides a model that systematically excludes animism, which might explain why, despite its undeniable theoretical advantages, it has little popularity outside of a small research community."
It's an interesting concept. I'd like to know what others think. I do have some animistic feelings about my programs including my functional programs.
This appeared on the LL-1 list.
Posted to critiques by Noel Welsh on 7/3/02; 4:29:22 AM
Discuss (6 responses)
|
|
| Joel on Programming Languages |
|
Why do developers choose one programming language over another for a given task?
Nothing very deep or new in this post, but it does demonstrate how one particular developer selects a programming language for a specific task (and he will probably get flamed for his choices.) Also brings up this issue of whether .NET languages just differ on syntax and what added benefits they provide. Both of these points have been previously debated here.
And for an initial critique:
Sometimes I choose raw C when I need blazing speed.
See language myth number 9.
Posted to critiques by Dan Shappir on 5/6/02; 2:24:31 AM
Discuss (8 responses)
|
|
| Evaluating a new programming language |
|
We describe our efforts using the Cognitive Dimensions framework to evaluate a new programming
language. We used a questionnaire approach to gather framework data related to the new language
and combined this with a traditional lab-based evaluation. With this approach, we were able to
validate the findings from the cognitive dimensions questionnaire by correlating them with the
findings from the lab-based study. From this, we were able to determine if it is feasible to perform
such an evaluation with usability participants who have no prior experience of the language being
evaluated. Our findings have implications for anyone intending to use the cognitive dimensions to
evaluate new notations or programming languages.
The language studied is C#.
I am far from certain that this type of study is the 'right' way to check language usability. But at least it is a bit more scientific than introspection...
Comments?
Posted to critiques by Ehud Lamm on 3/18/02; 2:04:53 AM
Discuss (4 responses)
|
|
| The developer's dilemma |
|
So today's developers will use one of three languages: Java, C# or VB.Net. How do these compare to C++ and VB, the languages that dominated the market five years ago?
So Ehud, looks like you will have to give up on Ada. I'm also wondering which one of these three Frank will use. I'm guessing VB.NET.
This is a terrible quote from a not-so-good article. But since its a featured commentary on ZDNet, I think its worth a look. This article has also spawned a thread on Slashdot.
Posted to critiques by Dan Shappir on 2/27/02; 4:50:06 AM
Discuss (2 responses)
|
|
| The Case Against C |
|
Oleg directed me to this essay.
Not that it is going to convince anyone, but this seems well written, and well reasoned (and I agree with the conclusion, anyway).
Posted to critiques by Ehud Lamm on 12/28/01; 1:04:29 AM
Discuss
|
|
| Java: Good and Bad |
|
Java is frequently contrasted to C++, as these languages seem to be used in the same problem space.
This article contrasts Java to C++ for developing large-scale applications. Instead of presenting a simplistic view ("Java is good but slow, C++ is dangerous") it breaks these languages down into features which help or hurt software development.
Posted to critiques by Dejan Jelovic on 8/8/01; 12:28:53 PM
Discuss (1 response)
|
|
| Server-side scripting languages |
|
This paper (found via PHP everywhere) compares PHP, Perl and Java servlets.
The paper is built around three examples of varying complexity. Each example is solved using each language, so you can make up your own mind.
This is how the paper summarizes the different language philosophies:
Perl creator Larry Wall says that he designed Perl to make the easy things easy while making the difficult things possible. By contrast, PHP makes some of the easy things even easier and still gets the harder ones done. Java makes the big things more scalable and makes everything more object-centered.
On the other hand, Perl makes a lot of things weirder. It's a simple language to learn, once you can get past the culture shock. PHP has removed much of the quirkiness from Perl, but in the process it has lost just a little of the power. Java makes the hard things easier, especially since a lot of them have already been done and can be included or inherited efficiently. But it also makes some of the easy things a bit harder than perhaps they should be.
Posted to critiques by Ehud Lamm on 4/20/01; 8:06:46 AM
Discuss (7 responses)
|
|
| Java Design Flaws |
|
(over on Wiki)
This page describes design flaws in java. In a manner more constructive than a LanguagePissingMatch, we ponder how the language could be made better at reasonable conceptual or implementation cost, and hopefully glean applicable insights along the way.
Contains a list of flaws, and you can express your opinion by voting (you can also add to the page, of course).
But be warned: A link to this page was posted on comp.lang.java.advocacy by Thomas Holenstein <thomas @ hex.ch>. Given the number of anti-Java bigots that hang out there, I don't expect any reasoned debate or unbiased voting to ensue.
Posted to critiques by Ehud Lamm on 4/12/01; 6:40:14 AM
Discuss
|
|
| Haskell v Ada v C++ v Awk v ... |
|
I've seen this several times, but don't think it's ever been posted here - a comparison of different languages used in a project for the US Navy.
I found it on Paul Hudak's home page, which also contains some other interesting (although less relevant to lambda) links: support for generating music in Haskell (expanded here); parsing natural language using types; and Fran (for reactive images) which is related to Pan.
Posted to critiques by andrew cooke on 3/20/01; 12:22:54 AM
Discuss (1 response)
|
|
| A skeptic's look at C# |
|
Over on JavaLobby
I found that the fundamental reason for this reaction is that Java is, if not quite perfect, as close as you're going to get to a purely Object Oriented language with absolutely no compromises.
A biased but quite lively discussion...
Posted to critiques by Ehud Lamm on 3/8/01; 2:42:43 AM
Discuss (1 response)
|
|
| A Critique of Standard ML, Andrew Appel |
|
I added a new department for language comparisons and critiques. Deciding if a link such as this one should go into a general category like functional or into critiques is, naturally, not clear cut.
Since the link above is SML specific, and deals with issues that are not general to FP, I chose to place it here.
The paper deals with a wide range of issues, from safety to syntactic quirks.
Posted to critiques by Ehud Lamm on 2/17/01; 2:41:02 AM
Discuss (2 responses)
|
|
|
