What I Hate About Your Programming Language
by chromatic05/12/2003
Author's note: based on voluminous comments, I've clarified a few places where my original intent was unclear. Thank you all for the feedback!
At a very high level, all programming languages are similar. They all require you to describe a problem to solve. They all require similar skill sets — a good programmer in one language will find his or her skills will transfer to another language.
Of course, at a practical level, there are important differences between languages. Different language families make certain techniques easier than others. You'd rarely be able to write a useful procedural program without any variables, but it's common in functional languages. Expressing a logic problem in terms of objects and classes will require a different approach than that of an imperative language.
Setting aside those differences and 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.
Language Philosophy
The philosophy of the language designer shapes the language, its libraries, its ecological niche, and its community. Pascal was a teaching language. C is portable assembly. Lisp syntax is very much s-expressions. Perl is expressive glue.
Consider what happens when someone proposes a great new language feature. There are several possibilities; the language designer may reject it outright, saying that it doesn't fit in the language. (That leaves the door open for someone to write or modify the compiler or parser to support the feature.) The designer might include it in the language by adding a new keyword or by making some other change to the core functionality. The designer might suggest it's better made available through some extension mechanism, such as being added to a core library or an optional library.
Of course, a language with general-purpose features has a way of escaping its original ecological niche. That's why some people use PHP on the command line, server-side JavaScript, and even C for network applications.
To summarize, languages often embody a philosophy. If successful, they're used in domains that the original designer may not have intended. They're often extended in ways the original designer may not have intended. (That's probably a mark of success.) Do these facts suggest any way to evaluate a language's goodness?
Language Goodness
Deciding a language is "good" or not is largely a matter of personal taste.
I prefer dynamic typing and don't care much for the static typing found in C
and its descendants. Part of that is personal taste — it feels like
premature optimization to decide that a variable will always fit into eight or
16 bits. (Yes, I know judicious typedefs can lower some of the
maintenance costs.) It's also practical; I don't write a lot of code that
would benefit from static checking. (A buddy writes drivers at a semiconductor
company. Static checking saves him time and effort.)
Barring the issue of personal preference, we're still left with rather
subjective criteria. Within a domain, it's worth analyzing a language by how
well it solves your problem. I'd hate to write a CGI application in straight
vanilla C; I'd go crazy trying to manipulate strings. On the other hand, there
are amazingly accomplished C hackers writing web programs like
mod_virgule. Familiarity with and fluency in a language are very
important.
It's also worth asking how often the language gets in your way. I once wrote a program to send out update notifications when a web page had changed. My original program was a 10-line shell script running on a Unix box. For various reasons, the final version was a couple of hundred lines of Java running on a Windows machine. Granted, my Java wasn't so hot, but the shell script just glued together existing Unix commands.
Another good question to ask is how well the language supports writing good and maintainable programs. I don't really mean that a language that enforces literate programming is necessarily better than a language that doesn't require you to declare variables. On the other hand, support for lexical variables, encapsulation, reusable components, and other good programming techniques certainly make it easier to keep using a program. This can be taken too far; a language that could prevent really, really bad programmers from doing really, really stupid things probably wouldn't be useful for much else.
It's reasonable to consider a language's supplementary virtues. Can you imagine programming in Smalltalk without using the browser? Would anyone use Java without the class libraries? I suspect if I got used to a good IDE, I wouldn't notice the pain of a strong static language as much — that's worth keeping in mind. Where would Perl be without the CPAN? Can a good user community keep people using an otherwise mediocre language? You bet.
Beyond these criteria, it's really hard to come up with a set of guidelines that make a good language. It's hard to judge the suitability of a language without practical experience in it — where pointer arithmetic is familiar to a C hacker when manipulating arrays, it's terribly unidiomatic in a language with queues and stacks as available data structures.
Besides that, the general purpose languages are all reasonably equivalent. It's not difficult to solve many of the same kinds of problems in any language. Given a good set of libraries, some experience using them, and a good IDE if necessary, a competent programmer could write an equivalent program in several different languages with roughly the same amount of work. Consider how many of the programs written today do one of the following:
- Manage a web site.
- Control a small GUI application.
- Put stuff in a database, process it, display it, and update it.
Even for more difficult tasks, decent languages tend to allow you to use existing libraries for trickier tasks like very fast XML parsing. C is really the language of the Empire, for better or worse. If there's a C library that does what you want and the language lets you use it, you're at least halfway there.
What's left? It's largely a matter of taste. That's where the friction comes in. Maybe personal taste is a poor reason for choosing a language, but it's a major reason for creating a new language. Language philosophy is subjective enough that it might as well be personal taste. Besides that, the first things a new user will notice about a language are syntax issues — where the language philosophy is most evident.
Language Badnesses
Of course, choosing any one language for a project often means not choosing another language; sometimes that's the most compelling reason. I've had projects where a manager said, "We're going to use language X because that's what VCs expect us to use," where language X was, in my opinion, the wrong choice.
Going further, differences in language philosophy present a barrier to learning new languages. This doesn't just apply to existing programmers. It also applies to new programmers — learning to think like a programmer is difficult enough without bothering with syntax issues, editors, compilers, linkers, and distribution.
In the spirit of demonstrating language subjectivity, here are several of my opinions on popular programming languages I've used and how I feel about them. They're completely subjective. They don't bother everyone. What I dislike about one language may be something you love. That's fine.
What I Hate About Perl
The syntax for working with anonymous data structures and structures by reference is ugly:
use constant HACKERS => 2; my $count = keys %{ $self->{groups}[HACKERS] };Writing extensions in C can be Byzantine. Perl's internals are full of macros. Sometimes they make life easier; other times, they hide a lot of complexity that you really should know. XS is a hybrid of Perl macros, Perl, and C, and it can get quite complex. Inline can't always protect you from that.
What I Hate About Python
The special case syntax for constructing a one-element tuple has always bothered me; the trailing comma seems unPythonic.
Half-hearted closure support means that enclosed lexicals cannot be modified. I could emulate real closure support with objects, but sometimes the functional solution feels more natural.
The whitespace issue isn't a big deal (I use a good text editor), but I've spent too long debugging make files to be comfortable with invisible-yet-syntactically-significant characters. Python does have the advantage that it doesn't dictate how much whitespace to use, but I'm still leery of issues with copying and pasting code from a web browser or a newsreader.
What I Hate About Ruby
The sigils that mark instance and class variables always stick out visually in an otherwise clean language.
The available English documentation is still exceedingly slim, compared to Perl and Python.
What I Hate About PHP
I seem to run into lots of special-cased features. For example, I always seem to try
new dir( $path )instead ofdir( $path ).There's no namespace support yet, and I've never liked name mangling to get around this.
What I Hate About Java
The inconsistencies between what the language allows and what the standard library actually does bother me. If operator overloading is so bad, why does the
Stringclass do it?Interfaces get around part of the lack of multiple inheritance, but I'd like to be able to reuse common code in ways besides inheritance. Mixins that don't require inheritance would be a nice touch.
The libraries and the interpreter aren't cleanly separated. There are ways (involving decompilers), for example, to get regex support in 1.3, but I'd prefer to upgrade the standard library and the interpreter separately sometimes, rather than in one big chunk.
I like the idea of checked exceptions in some situations, but forcing every method to deal with (catching or throwing) all exceptions that its child calls or may call can be tedious. I'd rather be able to ignore an exception and let it propagate upwards. Sometimes, I'd rather not worry about exceptions at all.
What I Hate About C
It's often used inappropriately. Unless I'm writing a kernel, a device driver, a virtual machine, or an interface to a C or C++ library, writing in C is a probably premature optimization.
Thirty years of growth and patches to the standard library have produced many, many similar functions with similar, terse names. Quick, Unix coders, what are the differences between
execl,execlp,execle,execv, andexecvp? If you're not using these every day, you'll be hittingman 3 execwhenever you see them.
What I Hate About C++
I find the template syntax ugly. I have no idea how to make it more beautiful, though.
It feels funny to add code that does nothing to prevent the compiler from helpfully adding code that does the wrong thing. Consider the default copy constructor, for example.
What I Hate About JavaScript
Okay, I really don't hate very much about JavaScript. It's pretty good for manipulating DOM elements, and I really like bookmarklets. Working around browser bugs and incompatibilities scarred me for life, though.
What I Hate About XSLT
I'm familiar with functional programming, but XSLT still feels more theoretical than practical. I really understand the benefit of not having to write yet another language parser, but programming in XML, by hand, feels really wrong. Maybe using a better tool would help.
What I Hate About SQL
The extensions I find most useful for a database generally aren't portable to other databases.
The approach that feels most natural is often really, really bad. I don't naturally think in terms of set operations.
Acquired Tastes
These are my preferences, based on the kind of work I've done and continue to do, the order in which I learned the languages, and just plain personal taste. In the spirit of generating new ideas, learning new techniques, and maybe understanding why things are done the way they're done, it's worth considering the different ways to do them.
The Pragmatic Programmers suggest learning a new language every year. This has already paid off for me. The more different languages I learn, the more I understand about programming in general. It's a lot easier to solve problems if you have a toolbox full of good tools.
I've learned several new techniques from branching out. For example, Ruby supports mixins with surprising ease. It's a natural way to solve certain problems where you might otherwise use a Decorator pattern. Seeing how Ruby uses mixins led me to ask how I might solve the same problem in Perl — and it's incredibly easy. It's not exactly a built-in language construct, but it's trivially easy to add, and now it's part of my standard Perl vocabulary.
Over time, my taste in languages has evolved. I used to worry about performance and variable-typing, but working with dynamic (or "agile") languages and learning to love test-driven development has biased me against strong-typing systems. Maybe learning a language like Haskell would balance my thoughts.
Every language is sacred in the eyes of its zealots, but there's bound to be someone out there for whom the language just doesn't feel right. In the open source world, we're fortunate to be able to pick and choose from several high-quality and free and open languages to find what fits our minds the best.
chromatic promotes free and open source software for O'Reilly's Open Technology Exchange.
![]() |
Essential Reading How to Keep Your Boss from Sinking Your Project Like it or not, your project needs management. Yet few good software projects can survive bad management. If you're a programmer on a high-visibility project, this PDF offers five principle guidelines for managing upward that will help you help your boss make the right decisions about setting project expectations, working with users and stakeholders, putting the project on the right track and keeping it there. The PDF also covers what problems cause projects to fail and how to fix them, and what you can do to keep your software project from running into trouble. Read Online--Safari Search this book on Safari: |
Return to ONLamp.com.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 250 of 266.
Next Page ![]()
-
Rebol
2006-04-14 19:38:17 notchent [Reply | View]
-
OCaml
2006-09-03 05:43:34 grimo [Reply | View]
There are concrete ways to compare programming languages. Comparing syntax is not really usefull. And all programmers are always convinced that the language they use is better than others...
But you can compare the expressiveness of languages concretely, by making a list of features they have.
The most complete language I know is Objective Caml. It has almost all the features you can find in other languages, making programming really easy and concise. But the most interesting thing is that the debugging time is reduced a lot because OCaml programs have very few errors (because of the typing system).
OCaml has been written by some of the best specialists of programming languages in the world, and includes all advances in research on that field (from all the world). When you know well OCaml you really cannot go back to another language!
-
OCaml
2006-09-06 12:54:23 chromatic |
[Reply | View]
Thanks for the response, grimo. I agree that comparing syntax is nearly useless; that was actually half of my main point.
I haven't ever looked at OCaml, mostly because it was difficult to find English documentation when I tried. It's on my list of languages to explore someday.
-
Which language is best
2006-03-10 16:59:34 lowellD [Reply | View]
I'm one of those "retards" that uses the often slammed language called Visual Basic. I never went to programming school and I don't program professionally, but back before Windows I needed a program to do a specific task that was otherwise not commercially available. I wrote the program in QBasic because it came on the computer. Was I supposed to know any better? It was easy to learn. Why waste my time learning a bunch of wierd, non-intuitive coding conventions. The program was just for me. I never intended to sell it. But over the years many people saw the program and wanted it; more than 2000 people have purchased the program. Of course, the current version is no longer in QBasic. But is written in VB5 and has a full standardized GUI running on all version of Windows. I know VB has it limitations. Everybody seems to think the language they prefer is the best. It may be the best for what they do but not the best for what someone else does.
So, where can a layman go to get a simple straightforward comparison of the various languages? How about a comparison of useful functionality rather than technical stuff. Things like: easy to code, speed of operation, print preview, long documents with a variety of formatting, good communication with printer, connection to email and web, etc.
-
Lack of imagination wrt Perl
2005-12-29 08:55:33 mkcmkc [Reply | View]
As soon as I read "programming languages are a matter of taste", my first thought was "must be a Perl guy". :-)
The list of Perl annoyances seems awfully short. Google on "Perl Puzzles" to see a more complete list.
-
What do you hate about Forth, Lisp and APL?
2005-10-16 00:45:32 znmeb [Reply | View]
I maintain there are only half a dozen unique programming languages in the history of computing: macro assembler, FORTRAN, Lisp, APL, FORTH and SmallTalk. So ... what do you hate about those languages?
Oh ... learn a new language every year? That implies someone has to come up with a decent new language every year. I'm learning Ruby right now. I go about one language every two to three years. Before Ruby it was R and before R it was Perl.
I never did learn Python or PHP, and I don't really think I want to. And I don't think I want to learn any of the "theoretical" languages like Eiffel, Haskell, OCAML, etc. I'll stick with Lisp for that. -
What do you hate about Forth, Lisp and APL?
2005-10-28 03:09:59 adrianh [Reply | View]
<blockquote> And I don't think I want to learn any of the "theoretical" languages like Eiffel, Haskell, OCAML, etc. </blockquote>
I really quite like Eiffel, and never really saw it as a theoretical language :-) The OO model is elegant, and Design By Contract is rather effective (although less effective than TDD in my experience.)
-
What do you hate about Forth, Lisp and APL?
2005-10-27 15:41:47 chromatic |
[Reply | View]
Hm, good question. I don't have a lot experience with macro assembler, but if you mean what I think you mean, text substitution macros just aren't fun.
Forth (or PostScript, which I have written) has the problem that I never trained my brain to work in the stack-oriented way.
Smalltalk is nice, but its "all of the world is an image" approach really gets in the way sometimes.
I would like Lisp better if it had syntax.
It's probably worth at least exploring one of the languages in your theoretical list. I've done some Haskell programming and it's a good way to expand your mind, especially with pattern matching function signatures and currying -- even if you don't get into monads or continuations. The choices for syntax annoy me in some places though. -
What do you hate about Forth, Lisp and APL?
2005-10-28 03:19:59 adrianh [Reply | View]
Hm, good question. I don't have a lot experience with macro assembler, but if you mean what I think you mean, text substitution macros just aren't fun.
Most macro assemblers these days aren't just simple text substitutions, but have some knowledge of "syntax".
However, even basic cpp style subs are a lot more usable with assembler (back in the day when I was writing a moderate amount of 6502 code I wrote my own :-). Since there isn't as much language syntax to confuse issues you don't get half the problems that you get in C for example.
I would like Lisp better if it had syntax.
You'd like Lisp better if it had more syntax m'thinks. But then, of course, you would lose many of the advantages having a first class representation of the AST gives you.
-
JavaScript
2004-08-16 18:38:40 wickline_ora [Reply | View]
Well, maybe you don't hate JavaScript for this, but I sure do...
The decision to use '+' for both addition and concatenation was very unfortunate. JavaScript is often used to validate/manipulate HTML form element values. Those values are not typed... they're just the value in the form.
If you '+' two form values (or a form value and something else) should you be interpreted as concatenating or adding?
Far too often, I've had to do foo.value*1 to enforce numeric interpretation and therefor addition instead of concatenation.
The same applies to using the same comparison operators for both numeric and string comparison.
Would it have killed them to add a separate concatenation operator and a few string comparison operators?
-matt
-
Don't forget ToonTalk!
2004-01-04 00:20:57 anonymous2 [Reply | View]
Yeah, C is nice for some things, and Haskell beats everything else for pure elegance. But I find I write most of my stuff in ToonTalk these days. Clients are always impressed by the animated helicopters and the mouse with the big hammer, two features you don't find in very many other programming languages (not to mention Dusty the Vacuum).
See http://www.toontalk.com and especially http://www.toontalk.com/english/computer.htm and http://www.toontalk.com/english/kidsask.htm
:) :) :)
-
Instead of a comment...
2004-01-01 08:44:57 anonymous2 [Reply | View]
...here are two links:
* All languages are not equivalent: http://www.paulgraham.com/icad.html
* It's better to be able to grow a language: http://prog.vub.ac.be/~wdmeuter/PostJava/FR-Steele2.pdf
-
have a look to Rebol
2003-11-01 10:41:19 anonymous2 [Reply | View]
Rebol isn't perfect but contains a lot of good ideas
- easy to install (run-time = 1 file ~ 400K)
- simple GUI
- a lot of predefined types
=> very short code
(I created REAL apps in 50 - 100 lines)
-
Why has nobody mentioned Eiffel ?
2003-06-19 02:59:27 anonymous2 [Reply | View]
Just a thought, I wonder why no one has mentioned Eiffel ?
I think it is a great general purpose language, nice and clean (like Ada).
Have fun.
<mr_jimmybob at lycos dot co dot uk>
-
Functionnal transducer languages vs. XSLT
2003-06-05 10:19:14 anonymous2 [Reply | View]
Some new XML oriented languages can replace XSLT and its lake of usability (XML syntax is... boring).
Take a look a XDuce (http://xduce.sourceforge.net/) and CDuce (http://www.cduce.org) this are functionnal languages with an ML-like syntax and nice pattern matching features (especialy CDuce...)
-
What about AWK?
2003-05-21 10:17:36 anonymous2 [Reply | View]
I have used awk for years, and I really can't find anything to hate in it. It's not a terribly powerful language, but you can do some pretty complex things with a few awk scripts piped together.
Anybody had a bad experience with awk?
-
Beside Taste
2003-05-19 02:54:17 anonymous2 [Reply | View]
Taste is not a good criteria for choosing a language. Environment seems another one.
Considering the number of mediocre programmers you can get compared to the number of good programmers, my preference is highly biased to a language which makes it hard to make mistakes.
Also most people arround are early trained in procedural thinking. Once you have forgotten the initial pain when you first learn to press every problem in a sequence of steps it seems to be hard to learn alternative ways. Strange enough.
The pointer is still a mistery to many people and they panic when they have look at a piece of C code using pointers. It's a pitty cause sometimes pointers can be cool, expressive and efficient. But at some point it seems to require knowledge of hardware design. And isn't the world full with memory overflow vulnerabilities. I wonder if people can not make it better or don't want to.
We're doing Java on the server side and I would not like to see what happened if we did it in something different than Java. And we have been very successfully using XSLT to separate layout from function. But training people XSLT is hard.
I try to look at a new language every other year. Unfortunately commercial environments do not let you change your major project language so fast, you have to stick to a compromise.
-
My favourite languages. (Objective C, OCAML and Ruby)
2003-05-17 05:47:49 anonymous2 [Reply | View]
Hangul, Latin and French.
Only joking.
Objective C is really worth checking out. It has most of the benefits of OO, with very little syntax change over C. It lacks class variables and multiple inheritence. Class variables are not really a problem because static variables can be used in the interface declaration files. Multiple inheritance is a pain. As the java user once said to the vicar. Either way, it's also a very well documented language and the memory management side effects of the model give a very smooth ride. Apple have hit the nail on the head by applying it to Cocoa. Although strictly speaking NeXt hit the nail on the head. You should check this out if you've done Smalltalk, because it uses very similar messaging protocols.
OCAML is seldom heard of but is piece of piss to learn if you've worked with LISP or ML or any functional language really. It's extremely fast, almost as fast as C and to boot has memory management. (http://www.ocaml.org - Free book available, GPL)
Ruby; one word blocks.
-
so many languages, so little time
2003-05-15 20:18:27 anonymous2 [Reply | View]
My favorite language is BLISS, but that's not a language for people who like complicated, difficult to master languages like C, C++, etc....
Fortran may be the most important language today; a very simple language which wasn't designed to be extended so the extensions came a cost.
FORTH is another simple language that is very powerful due to its builtin bootstrap nature.
G-code, aka RS-274, is a trip back three decades - only someone who have at least a few decades in the computer industry can truely appreciate its stunted development.
I haven't really thought about it for a quite some years, but I wonder if someone has updated Jean Sammett's computer language family tree.
It seems to me that the industry has stopped exploring the nature of computer languages, problems with and using programming languages, and all the interesting computer language discussions of the 60s and 70s... -
so many languages, so little time
2003-05-20 17:15:54 anonymous2 [Reply | View]
>It seems to me that the industry has stopped exploring
> the nature of computer languages, problems with and
>using programming languages, and all the interesting
>computer language discussions of the 60s and 70s..
You might be interested in looking at http://mozart-dev.sf.net.
-
better than C
2003-05-15 10:21:27 anonymous2 [Reply | View]
I read your article with deep regret. The most useful language I know of was not mentioned. I use PowerBasic everyday.
It produces faster and smaller code than C. It can address either complex or trivial problems in a snap.
Its chief, and only, deficiency so far as I can determine, it that it has a name that is unsuitable for mass appeal.
If "PowerBasic" had been called "Snap" or "Beano" or just about anything but "Basic" it would have been the longstanding hit of programmers. But the word "Basic" carries with it an implicit insult to programmers who know their own work is anything but "basic."
There would be justification for steering clear of PowerBasic if it were anything like VisualBasic, which I find to be so dreadful that it is unusable. There might also be lingering justifications for not using PowerBasic if it contained some of the limitations of its predecessors. But in its present versions for my purposes there is only one word to describe it: "ideal."
Since this is a statement in praise of PowerBasic. I would like to be clear that I am not associated with the PowerBasic company in anyway, except to be a customer.
Ike Jeanes
Pulaski,VA
-
PHP problems?
2003-05-15 09:14:17 anonymous2 [Reply | View]
PHP 5 is slated to have namespaces included. There's no test version yet to determine how well this will work, but that should fix one of his two complaints. The other is more of just familiarizing himself with the language. I doubt this can be fixed.
-
No RPG?
2003-05-14 22:27:55 anonymous2 [Reply | View]
I did RPG-II on an IBM System/34 in high school about 11 years ago. It was /interesting/ and not fun at the same time.
I migrated from screwing around in OCL to ARexx, and now to PHP-CLI. I'm very happy where I am.
-
Re: What I Hate About SQL
2003-05-14 19:25:41 anonymous2 [Reply | View]
Yes, SQL is often thought of as Not A Real Programming Language. I think there are two types of developers: those who think naturally in sets, and those who don't. Not that one is better than the other, but I think naturally in sets, and love the logic behind that approach. I tend to solve most of my biggest problems that way.
Really, I think SQL's biggest failing is that it is not set-oriented enough, nor is it particularly expressive. That's why triggers, procedural languages, and all sorts of proprietary extensions had to be developed in the first place. C.J. Date and a few of his associates have been campaigning for a better relational language for years (based on TutorialD, or Alpha, or whatever it might be called next -- see www.thethirdmanifesto.com) -
Re: What I Hate About SQL
2005-12-29 04:29:23 Scott_Kirkwood [Reply | View]
What I hate about SQL is that it's so inconsistent:
SELECT <columns> FROM <tables> WHERE <conditionals>
UPDATE <table> SET <column>=<value> WHERE <conditionals>
INSERT INTO <table> (<columns>) VALUES (<values)
Converting an insert into an update or select is more painful than it needs to be. I'd prefer:
UPDATE <columns>=<value> FROM <tables> WHERE <conditional>
and
INSERT <columns>=<values> INTO <tables> WHERE <conditionals>
I'd also make AND interchangeable with WHERE and trailing commas would be acceptable (like in Python), for example:
SELECT
A,
B,
C,
FROM myTable
AND a > 1
AND b < 1
-
Re: What I Hate About SQL
2005-12-29 09:53:44 ababiec [Reply | View]
Don't forget you can also use a subquery instead of a values list, so I'm not sure how your example address that scenario...
INSERT INTO <table> (<columns>) SELECT <columns> FROM <tables> WHERE <conditionals>
And INSERTs don't require a columns list if the values match the column order of the table.
Never mind examples such as...
INSERT ALL
WHEN order_total < 1000000 THEN
INTO small_orders
WHEN order_total > 1000000 AND order_total < 2000000 THEN
INTO medium_orders
WHEN order_total > 2000000 THEN
INTO large_orders
SELECT order_id, order_total, sales_rep_id, customer_id
FROM orders;
-
ALGOL anyone???
2003-05-14 14:23:05 anonymous2 [Reply | View]
This was the first language that I learned after ASM and is still one of the best. I don't think it exists in the bill gates world - ????
bobh
-
You whacked to note about REXX
2003-05-14 13:52:43 anonymous2 [Reply | View]
Why?
bob hamilton
-
Ideal language: Delphi w/ Clarion influence
2003-05-14 12:56:38 anonymous2 [Reply | View]
I'd love to see a delphi language/environment with Clarion's syntax for blocks, ifs, loops, and lack of the semi-colon terminator in favor of new-line. Clarion's syntax is the cleanest I've seen for these basic elements.
Check out this Clarion code:
if x = y
! number of statements doesn't matter
SomeProc('sdf', a)
loop i = 1 to 5
p = x * i
Message('p is ' & p)
end
elsif x > 3
! all loops start with 'loop'
loop while x = 3 and SomeFunc(x)
a = b * c + sin(b+c)
Message('a is ' & a)
end
elsif y = 4 and blah
! anumericvar is converted to string
Message(anumericvar)
else
halt('aarrgh!', -1)
end
No semi-colons and you don't need begin..end in some cases and not in others. Clarion dynamically converts between strings and numbers, and, as a 'general purpose' business language, returns 0 when dividing by zero instead of throwing an error. It supports file structure and window structure declarations (in the language itself) and is a natively event-driven language, with window event loops as just another type of loop in the language syntax. Unfortunately, all these neat features are much less flexible in the long term than the library based ways of Delphi. -
Ideal language: Delphi w/ Clarion influence
2003-05-16 12:27:29 anonymous2 [Reply | View]
Sadly Delphi/Kylix (Object Pascal) is often overlooked. Perl, Ruby, etc. are all find for scripts, but in most cases, a compiiled program in a better way to do. Delphi lets you program procedurally like C, or with Objects like C++, only the union is much more natural. It prevents you from making many stupid mistakes, while allowing you 99.9% of the power C has. It borrows some syntax from perhaps better languages (Oberon, Modula, etc.), but has a much bigger and more useful standard library. (Unofficially, anyway...) -
Ideal language: Delphi w/ Clarion influence
2003-05-14 13:57:11 anonymous2 [Reply | View]
You should look at REXX.
bobh -
Ideal language: Delphi w/ Clarion influence
2003-05-16 12:40:02 anonymous2 [Reply | View]
Hi,
I've looked at REXX, and it seemed nice (I used it on Amiga and OS/2). Last I checked though, it didn't compile, and also it doesn't have nearly the standard libraries that Delphi or Java has. (At least it doesn't have the mess that C has).
One thing that's often over-looked is that diversity is great, but when people write something in a non-compiled language like PERL, the users need to have the runtime interpreter, and often, libraries installed. I find it impossible to have my linux machine without having stuff like NROFF, PERL, PYTHON, RUBY, etc., that I will never use directly. I think it's great to have diversity in languages, but I don't think we need scripting-language-of-the-week club either. Most things probably should be compiled.
-
It has never let me down... FOXPRO (VFP)
2003-05-14 10:47:16 anonymous2 [Reply | View]
Fast Development – Easy to use – Robust – Dynamic use of Databases – It keeps up with the times – Simple application deployment – Good Reference tools on the web – Strong user base – 3rd Party Add-ons – Owned by Microsoft – Can make Apps for the WEB – Low Cost – And the Fox is Cute too! ************ FoxPro VFP8 – What are you waiting for! -
It has never let me down... FOXPRO (VFP)
2003-12-02 08:40:10 anonymous2 [Reply | View]
I python, perl, plain C and VFP. VFP is a joy to code. Except for python, I have found nothing superior in the "open source" world except for python. But python is a language when vfp is a full dev. environment. MS VFP team, continue the good work.
On my dream wishlist a "dev. environment" by "good old borland" at the driving seat, python as language and wxwindows as gui.
Only dreaming:) -
It has never let me down... FOXPRO (VFP)
2003-05-14 13:12:50 anonymous2 [Reply | View]
Some one Tell me why I keep hearing VFP is going to be dropped my MS! I just got a Copy of VFP7 and its great! Now I hear that ver. 8 just came out, can it be any better? Why is VFP such the ugly duckling? -
It has never let me down... FOXPRO (VFP)
2003-05-15 06:41:48 anonymous2 [Reply | View]
VFP is great. It has its own easy to deploy runtime. You can compile to .exe. Its IDE if excellent. It is complete with the front-end user interface, middle-ware code and it's own multi-user safe & high performance database engine (desktop). BUT: M$ (aka the Borg) assimilated back in the early 90's what was then a cross platform development tool. Now M$ vision of cross platform for VFP is multiple versions of Windows. Plus M$ can not make a lot of end-user money on a product whos runtime is free.
Bej - Philadelphia. -
It has never let me down... FOXPRO (VFP)
2005-02-01 18:38:51 Nurchi [Reply | View]
Microsoft Visual FoxPro is the best.
At first (we're talking about DOS times, about late 80's, early 90's) when Ms bought FoxPro, we (programmers) thought that Ms wants to "put it under the table" (to get rid of the competitor) to develop their BASIC...
But I made a lot of stuff in VFP (I am from Southern Russia).
In less than a week, I made a program for dental clinic and went to a "conference" and won second place in our province when I was in grade 11.
VFP ROCKS.
It compiles EXE for Windows, as well as APP, which is practically platform independent. It had this feature in VFP 5.0 (around 1994-1996), and the only places you could run the APP programs were (still are pretty much) Windows and Macintosh.
But think about it on the other hand, if you are running a Windows-based server, you can put APP to run in the browser, and it (theoretically) becomes platform independent.
But I don't know why it is not used in Canada (almost) at all...
There are no jobs here for VFP programmers (Ontario, probably some in Quebec, and most of the USA only)
Anyway, f**k off, whoever doesn't like VFP.
No one forces you to use it, if you don't like it.
If someone does, find another job.
Fisual FoxPro ROCKS!!!
I am currently learning C#.
Very good language, simple, relatively powerful and platform independent (not C# alone, but the .NET environment), similar to Java (just a little), and it is cool!
The only language I would prefer other than VFP.
C/C++ is powerful, but stupid. You know, it is like using a panzer as a hammer... Powerful, but why panzer?
Anyway, good luck. -
It has never let me down... FOXPRO (VFP)
2003-11-12 11:28:55 anonymous2 [Reply | View]
M$ is trying to get people to $pend more on their SQL server systems, than to let us use FoxPro which can do it all in one package.
You're right, M$ doesn't make anything on a free runtime distribution, but they are trying to change that. Take Windoze XP for example. There are installs that won't work because they aren't registered as a M$ Logo authorized install. Thus requiring the user to have the CD available whenever the application runs. Which it works fine on all other M$ OS versions. -
It has never let me down... FOXPRO (VFP)
2003-05-14 11:04:44 anonymous2 [Reply | View]
I wholeheartedly agree. The Fox Rocks! -
It has never let me down... FOXPRO (VFP)
2003-05-14 11:25:29 anonymous2 [Reply | View]
I agree. I develop in both VB & VFP & understand both equally well. Overall, for desktop database apps. VFP is simply remarkable.
Mark Achin
-
C rules, everything else vacuums lint
2003-05-14 10:41:47 anonymous2 [Reply | View]
OOP is for programmers who aren't smart enough to know how computers really work -- or who know how computers work, but are too lazy to care how much they abuse the cache, memory usage, etc.
C -
C rules, everything else vacuums lint
2003-05-25 09:37:07 anonymous2 [Reply | View]
You're an idiot.
C is just an abstraction built on abstraction built on abstraction .. As suggested by the responses already posted to your comment, you can drill down as deep as you want. Simply because someone uses OOP doesn't mean they don't understand how computers really work, you pretentious elitist pr|ck.
If somebody needs to write a program that solves some real-world problem, doesn't it result in a better product in the end that time can be spent coding ways to that real-world problem rather than dealing with these lower-level issues of cacheing, memory allocation, etc.? Isn't it better to be abstracted from these issues rather than to have to deal with them in addition to dealing with the problem at hand?
We write code to handle these problems of caching, memory allocation, etc., in order to more efficiently handle the real problems. Yes, oftentimes the program will be more efficient and you get to show off your l33t coding skillz if it was written from scratch in C, but I'll bet that the real-world problems solving and maintainability of a program written in a language abstracting the coder from these low-level issues will result in a better end product.
I will definitely agree that knowing how computers truely work at ALL levels will allow you to be a better programmer. Watching novice developers who have only ever known OOP oftentimes leaves my head shaking. If they knew the bigger picture, they WOULD be better at what they do.
Remember, computers are machines built to serve US. The minute you start coding to their limitations you're missing the point. The point is NOT to demonstrate your ability to manage memory allocation, the point is to use the machine to best serve you. -
C rules, everything else vacuums lint
2003-05-14 11:50:50 anonymous2 [Reply | View]
OOP is great for Code-reusablility and software management and large scale software architectures. Maintaining all that in C is a manager's nightmare. My $0.02
-
C rules, everything else vacuums lint
2003-05-14 12:10:21 anonymous2 [Reply | View]
Your absolutely right, but sometimes doesn't optimize to the fullest. C is for losers who don't understand how to write assembly code.
lol.
(not to be taken seriously ..) -
C rules, everything else vacuums lint
2003-05-14 16:18:48 anonymous2 [Reply | View]
What are you talking about? Assembly languages are for noobs that can't be bothered with learning all the opcodes and instruction formats of their chosen processor.
CPU's are for software weenies who are too dumb to design their own logic.
Logic gates are for morons too simple to string two transistors together. -
C rules, everything else vacuums lint
2003-05-14 21:33:45 anonymous2 [Reply | View]
Transistors are for simple minded, treehuggers who either can't figure out how a few million triodes and a couple megawatts of juice can make a perfecly good processor, or are to sissy to cut down a few thousand trees and dig up a national park to get some fuel for the power grid. The processor isn't going to be too fast, but of course it isn't going to matter much because you don't have to worry about some wasteful compiler producing less than optimal code as you are going to hard-wire all of your programs into the circuit anyway.
-
U suX0r!
2003-05-14 10:37:40 anonymous2 [Reply | View]
Ph33r m3 c0z u sUx0r! 411 14N6u463$ ru13 n00b!
-
U suX0r!
2003-05-14 16:20:25 anonymous2 [Reply | View]
Could you speak English? I don't read lEEt (or is that Perl?). -
U suX0r!
2008-03-22 16:09:35 Rex the Strange [Reply | View]
That's always been my point. Computers are for the convenience of humans, not the other way around. And we, in humanity, use words, not stupid symbols and groups of nonsensical characters to get our message across. So why should it be any different when we're talking to computers? They are our slaves. They should speak our language. If you want to be a slave to the way a computer talks then just go ahead and write your damn program in machine language (no, not an assembler - actual machine 1s and 0s).
That's why that ridiculous C family of languages (and by that I mean any language that employs those stupid C symbolic conventions: C, C++, C#, Java, Perl, PHP, JavaScript - the list is endless because people are too stupid to realize that it's pathetic gobbledigook that should be abandoned now before more damage is done to young, impressionable minds) is an anathema to human existence.
Use a language that actually uses words like Pascal/Delphi or Basic. Otherwise, show us how computer savvy you really are (and how stupid) by churning out those endless 1s and 0s.
-
Java; I want a destructor!
2003-05-14 09:43:34 anonymous2 [Reply | View]
nuf said. -
Java; I want a destructor!
2003-07-09 03:24:54 anonymous2 [Reply | View]
I find that funny, I was just looking all over my java docs and books trying to find a destructor in java...kind of bizarre that there is none!
And all the java advocacy crap about how c++ sucks because of memory allocation/deallocation problems...gee, you figure they never heard of putting your "new's" in the constructor and your "delete's" in your destructor -- I guess they haven't, since they don't even have destructors. -
Java; I want a destructor!
2003-05-22 17:37:56 anonymous2 [Reply | View]
finalize acts like the destructor for Java. -
Java; I want a destructor!
2003-05-15 01:11:36 anonymous2 [Reply | View]
That would be completely stupid. The whole point of the destructor is to free heap memory that might have been allocated as part of a data structure. Java has pretty good garbage collection, so this saves you the hassle. I mean, instead of saying delete blah, you can just say blah.finish() if all you are trying to do is complete something before the object is gotten rid of. This sort of thing can be equally easily done in Java without any explicit call that is reserved for freeing memory. -
Java; I want a destructor!
2003-05-18 18:20:29 anonymous2 [Reply | View]
The purpose of a destructor is to free resources (not just heap memory). Closing files, sockets, database connections, etc., even in the presence of exceptions, without having to remember to try-finally-release them can be quite powerful. Garbage collection is nice and has its place, but isn't a panacea. -
Java; I want a destructor!
2003-05-19 03:26:12 anonymous2 [Reply | View]
This is especially true in a object-oriented language. I have a stream. Is it a memory stream or does it represent a file, a socket, or something else that the garbage collector won't release (or that a finalize method will release too late)? If you don't know, then you'll have to remember to try-finally-close that stream. Even when dealing with memory streams. That's convenience? -
Java; I want a destructor!
2003-07-08 07:03:53 anonymous2 [Reply | View]
Unfortunately the presence of a destructor poses HUGE problems for a garbage-collected language. The garbage collector can't tell when it's safe to collect an object, it can't just drop all the objects when the program ends, etc. I too missed destructors, but try ... finally ... is a good substitute.
Don't use finally() (or python's __del__(), for that matter) as you would a destructor. They may never get called. Also, they pose problems for the garbage collector.
-
And what of C#?
2003-05-14 09:40:39 anonymous2 [Reply | View]
C# is a inconsistent mixture of C++, VisualBasic, Java, IDL, and Smalltalk. Blech! -
And what of C#?
2003-05-15 03:05:28 anonymous2 [Reply | View]
I've found that C# grows on me faster than any other language I've used. At first I was very disappointed, saying it was just 9% better than Java. I was dismissive of the funny ways they use the new and override keywords until I understood they had addressed an important set of problems.
Having used it a while, I'd say it's very nice. Perhaps the best single advantage that C# has over Java, however, is that when it burst onto the public scene, it was much more complete than Java was for the first several years. Including libraries and documentation. It is of course completely unfair that the C# designers had years to use and study Delphi and Java and C++ before committing to a design for C#. So what!
The single best thing about C# may be that it works just as the documentations says it does. This alone is worth the price of admission (which is steep).
-
Criticisms of Java were really criticisms of class libraries
2003-05-14 09:35:55 anonymous2 [Reply | View]
-
but i love and hate assembler.
2003-05-14 07:29:48 anonymous2 [Reply | View]
i don't need compiler, they are all gcc family with complexity. no matter what language name it, after all, it's son of C.
why don't you make it easy? -
but i love and hate assembler.
2003-05-15 01:23:48 anonymous2 [Reply | View]
You are a fool. Who can legitimately ever claim that writing in assembler ever simplified writing a practical program? There are situations where writing assembler might be useful like if you need a very efficient block of code that processes video or something, but in your situation, there is no doubt that a compiler could generate much more efficient code than you could ever write. In fact, even writing simple programs, not knowing well the underlying hardware will likely have you writing inefficient code. Unless your programs consist of pushing a couple things on the stack, and maybe taking a wild ride loading a storing a few things in memory, writing assembly will most likely only give you buggy code that is impossible to follow along that only runs on your architecture. -
but i love and hate assembler.
2003-05-14 16:22:56 anonymous2 [Reply | View]
You may not need a compiler, but you do need a grammar checker. -
but i love and hate assembler.
2003-12-31 19:25:49 anonymous2 [Reply | View]
Asm rulez! No compiler can improve the code like the human mind (if you know how to do it).
With asm you can control everything inside the code without "compiler defaults" junk!!!
Compilers are based on defaults that can generate small/inneficient pieces of codes to especific situations.
I write all my DOS/Win32/UNIX codes 100% on asm and, at least for me, my code is so clear as any other junk languages.
Asm only requires to know what you're doing with it, something that most "Hello World" programmers don't know.
DKZ -
but i love and hate assembler.
2003-12-31 19:25:33 anonymous2 [Reply | View]
Asm rulez! No compiler can improve the code like the human mind (if you know how to do it).
With asm you can control everything inside the code without "compiler defaults" junk!!!
Compilers are based on defaults that can generate small/inneficient pieces of codes to especific situations.
I write all my DOS/Win32/UNIX codes 100% on asm and, at least for me, my code is so clear as any other junk languages.
Asm only requires to know what you're doing with it, something that most "Hello World" programmers don't know.
-
php is also missing function overloading
2003-05-14 07:27:13 anonymous2 [Reply | View]
last time I checked, I couldn't do function overloading by param signature, which sucks major browneye. There was some wack way of naming the same function differently for each param permutation and using the main function as a traffic cop.
Granted, in Perl I just lazily shift off and do sanity testing in module, but when writing OO code I prefer to overload functions, particularly constructors.
-
You need to look at REXX
2003-05-14 07:25:47 anonymous2 [Reply | View]
Some great points on languages, but REXX beats them all in so many of the points you raise.
bob hamilton -
You need to look at REXX
2003-05-14 10:59:36 anonymous2 [Reply | View]
I liked some parts of AREXX -- on the Amiga -- mostly the idea of the standard interprocess communication scripting. However, I always had problems with the syntax -- figuring out what was actually being passed, or being processed. It was weird. (I think in C.)
I eventually did figure out how to do useful things -- my favorite is a script that controls 3D image rendering in Lightwave, uses an external image processing program to apply motion blur and watermarks, then loads the results into the Toaster frame buffer, and talks to a comm program that controls a SVHS single frame editing deck to write the frame out.
All possible, because these programs that didn't know anything about each other all supported an Arexx port.
I wish the same thing existed on Linux. Perl scripts and system() calls are not the same thing as interprocess communication. And don't get me started about that fu-"scripting" that gimp has.
-
You need to look at REXX for Linux
2003-05-14 13:57:13 anonymous2 [Reply | View]
REXX runs under all IBM os's including Linus and AIX
bobh
-
Programming in C
2003-05-14 07:23:31 anonymous2 [Reply | View]
I hate the huge vocabulary of C. I have a poor memory between my ears. I use PASCAL because I can do whatever I want and I do not need to use MAN to do it.
-
You *CAN* ignore checked exceptions in Java
2003-05-14 06:58:07 anonymous2 [Reply | View]
Don't program much in Java, do you? To "ignore" an exception thrown at you, just declare your method thusly:
public void myMethod () throws Exception {
}
With whatever return type, access control, name, and parameter list you need. Saying "throws Exception" ignores the entire group of checked exceptions. You can percolate this all the way up to the main method, which if it throws an exception, causes the default handler (dump the stack to stderr and terminate the thread) to spring into action.
-
You *CAN* ignore checked exceptions in Java
2004-03-30 07:11:18 typo [Reply | View]
While this is kind of true, you have to deal with the exception somewhere, unless you do something like
public static void main (String[]agrgs) throws Exception {...}
Then that kind of defeates the good things that try blocks do.
-
You *CAN* ignore checked exceptions in Java
2003-05-14 11:56:07 anonymous2 [Reply | View]
I think the point is that you're not "ignoring" exceptions when you have to include the phrase "throws Exception" in every method up the stack. -
You *CAN* ignore checked exceptions in Java
2003-05-14 14:25:23 anonymous2 [Reply | View]
Sorry, I don't write Java (yet).
But either one wants an implicit exception handler to percolate the exception (fi the ILE language compilers on the IBM AS/400) and thus one has to 'steal back' the exception one does want to catch or one has (must) to tell the compiler that one likes to pass the exception up. Either way you'll need to specify what you want.
If compilers were smart enough to read the mind there was no need to do any coding at all. (Oops, just told you my favorite programming language)
Of course, maybe this isn't a philosophical thread.
-
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 06:51:27 anonymous2 [Reply | View]
I hate zero-based array indexing. There is an IMMEDIATE disconnect when you declare an array to have 10 elements, then can only address up to element 9. Couldn't the COMPILER handle this transition so I can think about the array elements naturally?!?
What the heck is the ZEROth day of the week? -
C, C++, Java, maybe others - zeroth element arrays
2004-02-16 10:42:43 andrewjmarshall [Reply | View]
Here's the final answer and I DON'T want to hear any arguments, because they're WRONG.
For low/machine-level languages, arrays should be zero-based. There's too many technical reasons for this to argue against.
For ALL other languages, array bounds should be CONFIGURABLE. Sometimes you want zero-based (freaks), ALMOST ALWAYS you want one-based, and sometimes you want a custom base. Let's remember one of the prime tenets of OO - Encapsulation or keep your users insulated from your implementatation. Why screw your programmers because it's "easier" for the compiler? F*** the compiler! Why is it my job to make the compiler's life easier?
I spent 2 hours arguing this point with my brother-in-law (a UVa Computer Engineering grad), and he lost. So there!
Hugs and kisses,
Andrew -
C, C++, Java, maybe others - zeroth element arrays
2003-12-03 12:51:43 anonymous2 [Reply | View]
I believe talking about the architecture of the machine or the storage mechanics of the language is irrelavant.
An origin zero and one can BOTH be useful in DIFFERENT situations. What origin produces the cleanest algorithm for a person to follow?
(modulo arithmetic, use zero base)
A language that can switch between an index origin of zero or one globally inclusive of all functions, operators, classes, objects that might use indexing upon command should be implemented.
If the language could address multidimensional arrays, again the emphasis could be on clean algorithms.
Wait, that was done back in the early 1960's the language is APL. -
C, C++, Java, maybe others - zeroth element arrays
2003-10-31 20:22:38 bioinfotools [Reply | View]
Both 0-based and 1-based indexing can be useful in different stituations. Personally, I think this is one of the things Pascal got right. In Pascal, you explicitly set both the upper and lower bounds of arrays, which are bounds checked. You make indices any valid integer range, including using 0 and negative values. This way you get both 0-based indices (to masquerade offsets), indices starting in 1, or indices ranging over precisely whatever you like (e.g. -100..100). From vague memory you could even index arrays with characters or elements of sets. -
C, C++, Java, maybe others - zeroth element arrays
2003-07-20 23:27:21 anonymous2 [Reply | View]
Well, it's like some countries count the "first floor" as the "ground floor", whereas some other countries count "first floor" and "ground floor" differently...
Note that those countries that count the "first floor" as the "ground floor" typically count "lower ground" floors as "basements" (e.g. "B1" or "basement 1" level)... Hence skipping the "zeroth" floor entirely... Whereas "ground floor" countries count it as "zero floor", and count the "B1" level equivalent as "lower ground" level(s).
"0" index arrays has its uses, but from a memory management perspective in terms of C (and C++), it makes sense... For every other language, it MAY be different (JScript allows non-zero aligned arrays).
Just like different languages has its own uses, the indexing schemes has its own uses as well...
No use quarrelling over it, UNLESS you're designing a new language, then you can suitably implement the "proper" indexing scheme that SUITS the PURPOSE (not the language/architecture/etc). -
C, C++, Java, maybe others - zeroth element arrays
2003-06-30 05:41:05 anonymous2 [Reply | View]
The main reason I prefer 0-indexing over 1-indexing
is that modulo arithmetic works cleanly. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 17:24:19 anonymous2 [Reply | View]
Short version:
1. Ask not whether to start at zero or one. Ask whether to place zero at the start of the array or the end.
2. Ask not whether to use zero or one based indexing. Ask whether to use [0, 1) or (0, 1] based indexing.
Long version:
Think of the indexes as *between* the elements. Like inches on a ruler. The first inch is between the zero mark and the one mark. So we call that inch [0, 1). If we want the second and third inches together we want [1, 3). That is starting at the 1 mark and ending at the 3 mark. (Note that 3 minus 1 is the number of inches as nice side effect.) You also see this effect in birthdays. Your first year of live is between your zero'th birthday and your first birthday and so on.
Now programmer hate to have to write [n, n+1) (or [n - 1, n)) all the time so we need a shorthand. We can take either the first number (zero based) or the second number (one based). It usually wont matter unless your array can use negative numbers. The most common (but not only) case of this is a circular array where negative numbers index from the end of the array. Zero will have to be placed either at the end or the begining of the array (we're *not* going to number them like we do our years). So the real question is whether zero goes at the begining or the end of the array. (Keep in mind where talking about shorthand notation. They are really elements [0, 1) and [-1, 0).)
Note that 0 is an element of [0, 1) but 1 isn't so we should prefer calling it 0 instead of 1. This may be a bias because we could also use [0, 1], (0, 1), or (0, 1]. Let's examine these. I shouldn't have to explain why [0, 1] and (0, 1) are completely out of the question (ask any Math professor). So that brings it down to [0, 1) vs. (0, 1]. In a certain sence which we choose is arbitrary, but Mathematicians have generally settled on [0, 1). Maybe it's because they are more intrested in the set of non-negative numbers, [0, INF), than the set of non-positive numbers, (-INF, 0]. I don't know why but it *is* the convention to prefer [x, y) (read "x upto but not including y") over (x, y] (I have no idea how to read that).
-
C, C++, Java, maybe others - zeroth element arrays
2003-10-24 13:24:10 anonymous2 [Reply | View]
"Think of the indexes as *between* the elements..."
What an absurd way to think of an array index. An array isn't a continuum, it's a numbered sequence of discrete items, so the rest of your "(0,1] [0,1]..." argument is irrelevant.
How do you number three items in every other domain in life? 1, 2, and 3. The first element of an array of items should be array[1], the the Nth would be array[N]. An array whose highest legal subscript was N would have N elements.
Easy to count, easy to refer to, the least suceptible of all systems to off-by-one bugs.
this confusion comes from the fact that array subscripts in close-to-the-metal languages like C are just syntactic sugar for memory offsets. Naturally, the first element of an array starts where the array itself starts, so its offset is zero. my_array(N) is just my_array + N*sizeof(element). It's a pointer to a memory address.
Unfortunately, from the very start, the most used languages have been low level, like C, so programmers have just gotten it in their heads that arrays *ought* to be zero-based. Perhaps they should be in such languages, but they carry that legacy mindset with them even when they move on to high-level languages where memory offsets are irrelevant -- to where you are simply labeling a sequence of items. If language designers now try to label array elements 1, 2, and 3 as 1, 2, and 3 (instead of 0, 1, and 2), though, the experienced (read: "those with the most legacy baggage between their ears") scream about it, coming up with preposterous, strained arguments such as the one above, appealing to "mathematics" to explain to gullible people why the ordinary counting everyone uses for everything else in life is somehow not acceptible for counting elements in an array.
Nonsense.
-
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 01:41:27 anonymous2 [Reply | View]
I know that others breifly mentioned why the zero is used, but clearly a better explanation is needed to enlighten those that think that it should start at 1. An array is an address. It is not some magic black box that has numbers. The address points to the first element of the block of memory that is the array. So lets say we have 'int array[10];'. 'array' is the same address as 'array[0]'. So the point is that you are asking how much should be add to the address to get to the first element. Add nothing (zero). Now lets say that we had compiler that did the index beginning at 1. If we explicitely said 'array[1]' this could be easily coded in assembly to access with a 0 offset, but what if we had 'array[i]'. The assembly must access the value of i and then subtract one. This adds an extra instruction that is otherwise not necessary. Clearly you know nothing about pointer or else it would be obvious about the arbitrary choice between using one or another. If I say 'int * ptr; ptr = array;', I can say '*(ptr + n)' to mean 'array[n]'; Is it clear now why this is the way it is. You clearly don't program in C much and don't know about the underworkings of the architecture. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 17:50:13 anonymous2 [Reply | View]
You and all the other replies seem to forget
the most important thing: an array index measures
the distance of the element from the beginning
of the array. If you think otherwise, try to
write a piece of code that maps a 6 dimension
array into a the memory (which is a one dimension
array) in a language that starts indexing with 1.
The mess that you will see is the reason why it
is better to start with 0. Also, if you like
starting with 1, cut off the 0th inch from all
of your rulers and measuring tapes and try to build a shed (or do any job where you have to
measure things). I would like to see the result
or how far you get.
-
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 11:55:38 anonymous2 [Reply | View]
"You and all the other replies seem to forget
the most important thing: an array index measures
the distance of the element from the beginning
of the array."
First of all, the distance is not the element number, it is the multiple of the element number times the size of an individual element in bytes.
Regardless of that, here is where I disagree with you completely. The array index is for the PROGRAMMER. The offset is for the MACHINE. Becoming accustomed to thinking this way has nothing to do with the original point - which was that this is bending the humans to the machine rather than the other way around. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 00:33:37 anonymous2 [Reply | View]
This is like saying a hole in the ground is better than a flushing toilet, it is giving you what you want and is less difficult to implement. And what if you are on rocky ground?
I do not need to care about implementing multidimensional arrays into memory (that's the compilers task, right?), I just want to express my thoughts in the language easily. No cupboard in my house has a zeroth shelf. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 03:52:41 anonymous2 [Reply | View]
No, the cupboards in your house may not have a zeroth shelf, but they DO have bottom shelfs, which are really just the analog of the array index 0, in terms of sequence. In fact, I would propose that there really isn't a zeroth element in an array, aswell. (Much to the chagrin of what the "zeroth" jargon file entry author might have to say, I might add.)
Zero is the offset from the beginning of the array that you use to access the First element. Perhaps there is an inevitable blur in the distinction between the indexer and the indexee when dealing with arrays.
When conceptualising the digital representation of an array for your cupboard analog, you must note that it is neither wrong, nor right to assert that the first element in the array starts at 0; it is rather tradition, but useful nonetheless. Consider the following:
In Python, for instance, you can access the last element in the array with the value -1. If the first element were 1, then accessing the last element via 0 would seem rather unnatural, both mathematically and practically, as access is being performed with offsets in mind.
At the end of the day, it all boils down to the age-old philosophical quandary of the "half-filled cup" perspective. Either you approach the issue from the viewpoint that you are accessing the first element, with the quantitative equivalence of 1, or you are accessing the first element at the offset from the bottom/start of the array, or the sequential equivalence of 0.
Trying to convince anyone that they are wrong in this matter is simply a fool's toil. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 13:15:40 anonymous2 [Reply | View]
Because it's not always just a compile time fix. If a variable is used in the index, the 'minus one' must be done at runtime. In math intensive stuff, this can be devastating. The best thing I think is a 1-based default, and an option to revert to 0-base on specific arrays. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 08:46:50 anonymous2 [Reply | View]
I can't imagine *not* using zero-based arrays. Why waste a perfectly good digit? -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 09:29:51 anonymous2 [Reply | View]
I will assume your response was *not* tongue-in-cheek. (I posted the message you replied to.)
Are you suggesting that *not* using zero means we may run out of digits? Ridiculous. Zero is not an element number - it is an offset.
This is an example of bending the humans to the machine, rather than bending the machine to the humans. IMHO, a fundamental mistake in the approach. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 09:55:38 anonymous2 [Reply | View]
The "Why waste a perfectly good digit?" bit was tongue-in-cheek.
But I've been programming so long I really can't imagine not using zero. It's second nature to me now. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 10:54:13 anonymous2 [Reply | View]
why arrays indexed from zero? cos everybody is used to them. maybe if we all started indexing arrays from 1 back in the day it'd seem sensible, but it has become convention. i'd find it weird if i moved to a new language and found the arrays indexed from 1, it'd spongle all my for-loop logic & annoy me every time i forgot it. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 14:39:09 anonymous2 [Reply | View]
Naah, you don't really want me to reply with a list of languages that do suport arrays starting 'at one' do you:)
Don't be worried if you ever encounter one though, those languages do not support for-loop logic either.
You'll indeed need an all new logic:
the first is in position one,
the second is in position two,
...
the Nth is in position N.
Hey, I really do like C, but not really for business processing. -
There's a zeroth element?
2003-05-14 13:08:17 anonymous2 [Reply | View]
Maybe I'm backwards, but I rarely use the zeroth element. I do know that C and its pointer arithmetic is why there is a zeroth element. But unless the problem absolutely requires it, I just ignore it like a bit of grissle on my steak. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 07:32:21 anonymous2 [Reply | View]
Zero-based indexing isn't so bad. If you MUST, you can alwas use enumerated indexing, or fake enumerated indexing with some constant definitions.
And, for things like 'cron,' the zeroth day of the week is Sunday. :-)
-
C, C++, Java, maybe others - zeroth element arrays
2003-05-14 09:33:22 anonymous2 [Reply | View]
My point was that to think about the thing in a way that is consistent with the tangible world I am forced to treat the concept of zero as something other than zero.
If you're counting your children, which one is the zeroth kid?
Bending the humans to the machine, rather than bending the machine to the humans. Bad approach, IMHO. -
C, C++, Java, maybe others - zeroth element arrays
2003-05-15 02:07:51 anonymous2 [Reply | View]
Perhaps you should move to COBOL :-), where the first element of an array is addressed as...... 1. -
C, C++, Java, maybe others - zeroth element arrays
2003-09-18 13:18:15 anonymous2 [Reply | View]
This is a bit late, but here are my $0.02.
I like arrays in pascal with bounds from -n to +n: var a: array [-10..10] of integer; It is very natural, simple and with run-time bounds checking also very safe. With arrays like pascal's much of current buffer overrun exploits would (probably) not exist! -
C, C++, Java, maybe others - zeroth element arrays
2005-02-01 22:58:52 Nurchi [Reply | View]
As people mentioned before, Pascal had the best implementation for the indeces of the arrays, when you can specify the lower and upper limit of the array.
But as we all know (well, most of us) the 0-based arrays go many years back, when C was created (actually, way before that).
As we know, any array in C/C++ (C style array, not <Vector>) is just a pointer to the first element of the array, so declaration:
int[] a;
is equivalent to:
int* b;
The number in square brackets indicates offset from the first element, so
"a[0]" means the same as "*b" and "a[5]" means the same as "(*(b+5))"
It was made this way, some people think it is stupid, but talking about all the stupid things that happen in our world, let's blame Hitler for..., but would anything change?
Just understand the concept and be consistent with it. I think it is kind of cool to use
for (int i=0; i{
//Do something here
}
The idea is that you go from 0 to 'i' strictly less than whatever, and as long as you are consistent with it, ...
I think, the bounds of the arrays are fixed and there is nothing we can do, and I am used to it, and I personally (some of you might not agree, but I don't care) think, it should be this way now. It is like this, and it shouldn't be changed.
AFAIK (As Far As I Know) even VB.NET has 0-based arrays now, starting from Visual Studio .NET 2002 (correct me if I am wrong).
Anyway, I think, discussions are OK, but when people argue about what is better, and what is worse, it is just stupid.
I (now) prefer 0-based arrays, and it would be hard for me (at least for the first time) to switch back to 1-based...
Everyone should be good at something. If you're good at 1-based, there you go, use whatever programming language you want to use, or just create the array 1 element larger than you actually need it. That way you waste some memory on element with index 0, but you for sure can access elements from 1 up to (and including) MyArray.Length
OR MAKE YOUR OWN DAMN COMPILER!!!!!!!!!!!!!!!
Good luck.
P.S.
C makes it easy to shoot yourself in the foot;
C++ makes it harder, but when you do,
it blows away your whole leg."
--Bjarne Stroustrup
-
Aspect s to resolve some Java complaints
2003-05-14 06:28:03 anonymous2 [Reply | View]
A nice way to get around some of the complaints about Java lack of multiple inheritance and checked exceptions is to use Aspect oriented programming.
Using AspectJ (http://www.aspectj.org/) one can easily silence checked exception by wrapping them in Runtime exceptions. It also quite easy to provide common behaviour without multi-inheritance by writing an aspect that will be applied on a implemented interface.
There is a lot of other nice thing you can do with apsects such as adding authentication/authorization to existing code without any change to the existing code, providing consisten logging throughout the application, etc. It really worth checking out.
-
Great Article
2003-05-14 06:21:59 anonymous2 [Reply | View]
Kudos to Chromatic! His writing skills are now coming to par with his coding. Definately becoming one of my favorite article/opinion writers. Even when I disagree I can respect his point of view.
-
Using C for CGI programming is easy...
2003-05-14 06:10:46 anonymous2 [Reply | View]
The author said: I'd hate to write a CGI application in straight vanilla C; I'd go crazy trying to manipulate strings.
Response: Several free C tools are available that do the string manipulation for you. I've tried several but the one that blew me away is called "uncgi". If you work in Unix you really should take a look at uncgi. Uncgi takes all incoming information from an HTML form, places it into Unix environment variables, and then runs your program. All your program needs to do is use function getenv() to read everything on the form. Uncgi opens up html forms processing to a C programmer almost immediately. Note that uncgi is actually language neutral. Any language that can read environment variables will work. Here's where to get uncgi:
http://www.midwinter.com/~koreth/uncgi.html
-
Using C for CGI programming is easy...
2003-05-14 07:53:46 anonymous2 [Reply | View]
Which just means you trade parsing strings fed to the program for parsing strings collected from environment variables. Same core problem; parsing strings with C is tedious and provides boutiful opportunities for errors.
-
Fredrick Brooks
2003-05-14 05:44:12 anonymous2 [Reply | View]
We were just talking about a related topic yesterday and I think it is appropriate to note that for all their differences today's present crop of 3rd and 4th GLs function at about the same level. Fred Brooks pointed this out many years ago in "No Silver Bullet", IEEE Computer. I said it once (IEEE Computer May 1999, Letters to the Editor) and I'll say it again: every programmer needs to read the Brooks article.
-
Perl and CGI . . .
2003-05-14 05:35:20 dausha [Reply | View]
Overall, I enjoy programming in Perl. However, I hate the many different flavors of Perl CGI programming. Too many of them don't quite do it well enough and the 'discussions' that happen when looking for the right one can be irritating. So, when it comes to CGI, I use PHP. -
Perl and CGI . . .
2003-05-14 06:33:46 anonymous2 [Reply | View]
I have no idea what you're talking about. CGI.pm has been the standard perl CGI module for years. Nobody uses anything else.
Besides, less people are using CGI anyway. Most likely you're not using PHP for CGI, but you don't even know it. -
Perl and CGI . . .
2003-05-14 08:02:13 anonymous2 [Reply | View]
Yes, there are some people who do use something other than CGI.pm though I will give you that most perl programmers working with cgi do use CGI.pm.
CGI.pm is just way too bloated for my personal tastes, so I wrote my own which is very compact, extremely quick (especially in comparison to CGI.pm), and has just the data retrieval and parsing subroutines I want (which is what most perl programmers use CGI.pm for anyway). It does both get and post with mime support, and is compatible with both windows and linux. Haven’t really tested it else ware. -
Perl and CGI . . .
2007-02-11 02:01:21 dave_doyle [Reply | View]
It's already been done. CGI::Simple is pretty widely used for just that reason. CPAN is your friend.
-
What is wrong about Ada ?
2003-05-14 04:46:19 anonymous2 [Reply | View]
Ada has saved me for a lot of work hours
giving me time to think about the actual
problem to solve... -
What is wrong about Ada ?
2003-05-15 12:32:08 anonymous2 [Reply | View]
Personally, I loved Ada.
The problem with Ada was that the entire run-time environment had to pass the DOD suite of tests, meaning an Ada environment tended to be large. Not large compared to today's suite of standard libraries for C, C++, VB, etc.
No subset of Ada need apply, nor any super-set of Ada, either. And, in order to do anything really low level, all the vaunted portability of Ada (due to the tests) went out the window.
A wonderful, powerful language (with a poor IDE, and debugging facilities BTW) was overtaken by the Visual languages, with better IDE's and great debugging, but lots of warts from the past. -
What is wrong about Ada ?
2003-05-15 06:09:17 anonymous2 [Reply | View]
Jeff Dunteman ( http://www.duntemann.com/ was a primary groon behind PC Techniques and Coriolis, but I think they changed to Visual Developer, or something, a few years ago ) said Eiffel ( a gnuular version at http://smarteiffel.loria.fr/ ) was "Ada, done right!"...
I don't know if you've compared 'em... -
I agree....
2003-05-14 08:15:24 anonymous2 [Reply | View]
Ada is a really excellent languange.
It is a powerful as C/C++, but without the design flaws in C that lead to bad code and holes like buffer overflows, so beloved by crackers.
I think that the problem is that like most things, programming is a popularity contest.
Languages are not chosen for their suitability to the task, but rather they are 'cool' this week.
Point in case, look how many silly people consider themselves serious application programmers because they make 'applications' in Visual BASIC.
Or among open sourcerors, every problem can be solved with Perl and or C.
It's time to put away the silly, childish bias and make choices based on reason.
If this were so, I'm positive Ada would be hugely more popular than it is.
Tach. -
I agree....
2003-06-08 23:42:38 anonymous2 [Reply | View]
I actually love Visual Basic, however its strength --easy to learn the basics-- is one of its weak points.
I agree that there are too many idiots that use VB to churn out the most horrid of applications... ugly and unintuitive gui, spaghetti code, using 2mb ActiveX controls in place of a couple of declared functions in a standard library...
it's nothing less than embarrassing.
Too bad it's a Microsoft-specific language, which means that its lifecycle has a definite end, and it's not going to be on any platforms besides Windows and the Mac.
(I would very much love to use it on POSIX machines.)
VB may not be as close to the hardware as C, but then again, it's not designed to be. Its purpose is to encapsulate the fucntionality of lower-level technologies, including C, ASM and the system kernel.
The philosophy behind VB is to feed the machine an algorhythm, and let the MACHINE figure out the answer. That's what computers are for -- to compute expressions.
There are of course times when you need to step beyond the language's safety net, and that's why experienced VB developers know how to directly access memory (yes, it can be done), use functions and types from the Windows kernel and object files written in C.
It certainly wouldn't be the ideal language with which to write device drivers or embedded software, but on a platform/machine that is pentium-based or beyond, VB's abstraction is NOT a con.
When you talk about 'silly people' creating applications, please keep in mind that any language can be used to create drivel. -
I agree....
2003-05-15 02:59:27 anonymous2 [Reply | View]
I'd largely agree with your central point (not about Ada - about people choosing languages based on their suitability to solve the task at hand, or the kinds of tasks they face in their line of work). One ceveat: popular languages generally mean more time and effort goes into the compiler (interpreter) and any support software (IDEs, libraries, etc.).
If this weren't true, I'd be off exploring Oberon and other things all the time...
-
All languages are not equal!
2003-05-14 04:30:58 anonymous2 [Reply | View]
see http://www.paulgraham.com/icad.html
-
Familiarity with and fluency in a language is very important.
2003-05-14 04:02:08 anonymous2 [Reply | View]
They certainly is.
-
Java problems...
2003-05-14 03:57:48 anonymous2 [Reply | View]
"If operator overloading is so bad, why does the String class do it?"
What String does isn't really operator overloading. It is a defined part of the language that exists for simplicity.
Also, what is done with String cannot actually be achieved with operator overloading mechanisms as they exist in other languages; it is a construct which is compiled into code that uses an entirely different class ('StringBuffer') to provide an efficient implementation that wouldn't be possible using String, which is immutable.
"I'd like to be able to reuse common code in ways besides inheritance. Mixins that don't require inheritance would be a nice touch."
Have you considered working with a pattern where a private member contains a reference to an object of the type you want to reuse code from, and then this is used within your class? I find this pattern very powerful, and useful in a lot of cases where people naturally turn to multiple inheritance in C++. In many cases, it is a lot easier to understand when reading the code, too.
"The libraries and the interpreter aren't cleanly separated. There are ways (involving decompilers), for example, to get regex support in 1.3, but I'd prefer to upgrade the standard library and the interpreter separately sometimes, rather than in one big chunk."
Is there any real reason they should be? I tend to think of a Java installation as a virtual operating system that runs on top of your own. Would you expect to be able to back-port Windows XP features so they were available on Windows 2000?
"I like the idea of checked exceptions in some situations, but forcing every method to catch all exceptions that its child calls or may call can be tedious. I'd rather be able to ignore an exception and let it propagate upwards. Sometimes, I'd rather not worry about exceptions at all."
Simple solution: add 'throws Exception' to the end of all your method declarations. It'll annoy anyone who isn't lazy and has to interface with your code, but it works just fine as a way of declaring to the compiler that you're not interested in the exceptions at this time.
-
Java problems...
2003-05-22 09:32:51 anonymous2 [Reply | View]
Just a note on checked exceptions. It may be annoying to have to declare everything in simple code that doesn't care about errors, but when you scale up to a large code base maintained by multiple developers, and requiring sophisticated error handling, checked exceptions are a major time-saver. I work on C++ code that makes heavy use of exceptions, and we could probably have saved weeks of developer time if C++ could do proper exception checking in the compiler.
-
What I really like about JCL
2003-05-14 03:41:30 anonymous2 [Reply | View]
IS THAT IT IS ALL UPPERCASE AND 80 COLUMNS AND STARTS WITH //.
However, the most important reason I don't use perl it it's 'cuteness' - I feel annoyed shitless by all this 'wow, ai'nt I just soooo cool' style, like using 'bless' as a command. Good grief.
-
Operator overloading in Java
2003-05-14 03:16:09 anonymous2 [Reply | View]
You wrote:
The inconsistencies between what the language allows and what the standard library actually does bother me. If operator overloading is so bad, why does the String class do it?
------------------------------------------
The philosophy behind that may be that overloading is not necessarily intrinsically "bad", but has the potential to generate unintuitive code.
The one supported instance of String concatenation is a natural and intuitive use of overloading.
Also, to eliminate it just in principle for consistency would deprive Java programmers of an extremely useful timesaver.
-
Operator overloading in Java
2003-05-17 19:41:31 anonymous2 [Reply | View]
> The philosophy behind that may be that
> overloading is not necessarily
> intrinsically "bad", but has the potential
> to generate unintuitive code.
On the other hand, if you've ever tried to make a nice matrix Class, you realize why operator overloading is so useful. Having the option available means you are able to apply a more natural coding style when it applies. Further, I have seen far too many unintuitive method and variable names to accept this argument.
> The one supported instance of String
> concatenation is a natural and intuitive
> use of overloading.
To continue my point, having to write something like
u = v1.add(v2);
to add two vectors (as used in Physics, i.e. magnitude and direction) is much more awkward than
u = v1 + v2;
in this context, since this style of infix mathematical notation is the most natural for the problem domain of Physics.
> Also, to eliminate it just in principle for
> consistency would deprive Java programmers of
> an extremely useful timesaver.
I agree that I wouldn't be as happy programming Java without the String concatenation operator. However, my argument for consistency would be in support of a general operator overloading mechanism rather than elimination of String concatenation.
$0.02
-- Tahoma
-
Operator overloading in Java
2003-05-14 16:24:49 setok [Reply | View]
That is one thing that annoys me about Java: the way some committee somewhere decides to leave things awkward or inconcistent just because they believe I am a bad programmer. It's a programming language for corporate entities who don't trust their employees. Good programmers should be given absolute power. If they create a mess it's then give them the blame. Don't make the better ones suffer because of that possibility. -
Should have required StringBuffer
2003-05-14 10:07:23 anonymous2 [Reply | View]
I've seen string concats via + --way-- overused and completely unnecessary. For consistancy, they should have required StringBuffer. To the developer, it's still operator overloading. The implementation of that overload (preprocessing during compilation would be a better term) is irrespective to the simple fact that the language bars using + between Objects, yet Strings are allowed to break this rule.
Essentially, Java should have set a single standard and stuck with it.
Java's single compile and run certainly beats the pants off the compile / link / run tedium with C/C++.
-
Why C sucks...
2003-05-14 02:35:00 anonymous2 [Reply | View]
I recently wrote another article here, before this one:
http://projectz.org/?id=182 -
Why C sucks...
2004-03-18 07:15:41 kuashio [Reply | View]
My comment is very similar to all others'
I think you are VERY wrong about "Why C sucks"... Actually, I think that your article has only one thing wrong: the title. It should be titled: "Why C Rules..."
And what's all that about newbies? (a.k.a. lamers)
C does not become newbies! Period.
All the things you mention in your bad-language-based article as being "bad" about C, are actually the things I love about it.
Boolean variables force you to write more code, resulting in larger and slower programs. Is it that hard to believe that "false", "NULL", '\0', etc. all equal ZERO in C?
And don't mess with the ?: ternary operator. Even Visual BASIC (a programming language intended for retards) has a function called "iif()" that does the same thing (sort of).
That's about it. Thanks for reading. -
Why C sucks...
2003-05-15 02:15:13 anonymous2 [Reply | View]
As many others said, you have some points, but these are only the reasons why C is GREAT for what it is. It is a low level language. Who said that people who aren't programming kernels, (and other things .. but you get the point), should learn C. #includes are part of the isolation compilation/linking/relocation part of a compiled laguage. It is necessary to have reffereces to things in other files such as function declarations or external variables. Since you must declare something before you can use it, headers are often used for prototypes. This type of use leads to things that can be thought of as bad style for new programmers as you have mentioned. Either way my point is that it is for the purpose of fast compilation that it is structured in such a way so that multiple passes don't have to be made through code and refferences to external entities are intentional and not a spelling error. A computer allows processes to have basically a stack and a heap, and C is the simplest way to directly access these in the way that it really is being done by processor instructions. I agree that other languages like Java for example give you a larger layer of abstraction in how it handles things, but that is why beginners should use Java and not C. C is the simplest, most direct control of the basic computer architecture while Java is some nice fluffy language that is as benign as a fluffy bunny. So my point is that people who don't understand what C is controlling should not use it. C is great the way it is. -
Why C sucks...
2003-05-14 16:45:05 anonymous2 [Reply | View]
I agree with some of the points in the article, but I think most of the complaints fall under the category of "How C is Misused," rather than "How C sucks." C was designed to be a portable assembly language in which to rewrite Unix so that it would be portable to more than one machine. It has obviously succeeded in that capacity. C was not intended to be a general application language, a teaching language, or the parent of a high level, general purpose language (C++). I don't consider it a failure of C that it hasn't worked out well in those capacities, but rather a failure of its users to realize when a different language would be better. -
Why C sucks...
2003-05-14 12:25:14 anonymous2 [Reply | View]
your "for loop" example is incorrect. the way you have it written is the way the zero-impaired newbies you talk about might think it works:
i = 0;
while (i<10) {
i++;
/* some other stuff */
}
in fact, the statement:
for (i=0; i<10; i++) { ... }
actually translates to:
i = 0;
while (i<10) {
/* some other stuff */
i++;
}
(increments i AFTER it does the work, not before) -
Give me C syntax or give me death!
2003-05-14 10:59:47 anonymous2 [Reply | View]
Some good points, but the funny thing is: If I were to write an article on why C *doesn't* suck, I'd include quite a few of the same issues you did. -
Why C sucks...
2003-05-14 07:59:25 anonymous2 [Reply | View]
I enjoyed your article on why C sucks (and what would suck less). I agree with many of the issues raised there. However, I would like to point out one area on which I am in strong disagreement:
We should not blame the language if the newbie programmer faces difficulty with its constructs. It is one thing to say a language has readability or even learnability issues. It is quite another to say that "it would not be clear to the newbie why this would work/fail". Someone who lacks full knowledge of a language has NO business doing serious work in it.
But all that aside, I understand where you're coming from. I am fluent in C and know all of its constructs, but I still have great difficult with actual examples of it (including my own).
Btw, IMHO, I share your sentiments about Pascal/Delphi, but I would really appreciate it if they changed "begin" and "end" to "{" and "}", respectively. -
Why C sucks less than Pascal, anyway
2003-05-14 21:11:09 anonymous2 [Reply | View]
The first programming language I learned, after DOS batch script, was C. (Taught myself; bought and borrowed books, drove my wife nuts with my face buried in the computer at night.) At the company I was working for back then (1989), it was my only option other than BASIC - and it did the job well.
I needed to do complex mathematics and manipulate ASCII files; BASIC chokes on ASCII files, especially when the number of whitespace characters on a given line of text is unpredictable. C, on the other hand, doesn't care; sscanf() is your friend. I wrote some great stuff back then, heavily commented so I could trace what I was doing later.
Nowadays, I'm stuck with Visual BASIC because that is the only scripting language our some of our CAD software understands. I feel like I've been sent to Programmer's Hell!
Sure, I still write plenty of csh scripts at work, and bash scripts at home, but I rarely find use for C anymore. Or, I should say that I am rarely able to implement it. They won't give me a compiler at work, and I don't have admin rights to install my own there. (And they don't even have Perl on my Unix box there! The barbarians!)
-
Java
2003-05-14 02:05:43 anonymous2 [Reply | View]
Java does not support operator overloading so neither does the String class. What happens is that the compiler automatically creates a StringBuffer class for you and appends() various stuff together. It was designed to make life easier for the programmer. Do everythign by hand if you want - it won't make a difference.
It's exception handling tediousness is necessary to ensure the security of the language. Take it or leave it.
I agree about the library issues. I have multiple versions lying around, from 1.1 to 1.4 and also the microedition version. It sucks to have to change the classpath each time i want to compile something. -
Java
2003-05-14 09:47:11 anonymous2 [Reply | View]
Actually Java programs cannot be made exception-safe: the runtime can throw a RuntimeException at any time it sees necessary; no matter how many try-catch's you put on your code, it will break badly... (even if you start catching RuntimeExceptions in your code, it will be moot, either it finally reaches toplevel or you have to kill the program... why did the runtime excepted? it's not worth the trouble, an it makes the code extremely verbose, entangled and filled with distracting noise... You catch where you need to, no more (Python, for example, manages this much better, you only have to be aware of it).
best regards, -
Java
2003-05-14 02:11:44 anonymous2 [Reply | View]
The unwieldy syntax for getters and setters! Sun could learn much from the simple syntax of Delphi properties.
Ditto for the lack of enumerations. JDK1.5 introduces these, but lets us set the value of each (Like c++). So no chance of introducing Sets to the language later (Enums must be zero based to allow efficient set implementation) - Again, learn from Delphi!
-
What I hate about Tcl
2003-05-14 01:29:17 anonymous2 [Reply | View]
It never gets mentioned in articles like this. -
What I hate about Tcl
2003-05-14 02:41:45 anonymous2 [Reply | View]
simply because it's out of fashion as the look and feel seems out of place on most platforms. It's not even "fast" or "slim"... I guess not many people bother learning TCL anymore, do they? -
What I hate about Tcl
2003-05-14 05:34:17 anonymous2 [Reply | View]
I love tcl and I learned it:
run everywhere: M$-Unix-Apple
c syntax: coming from c it was easy
list+ associated array: so powerfull
extension+package: so easy to do
glue: need a gui: use tk and bind the logic with your favorite language
need more :) -
What I hate about Tcl
2003-05-14 07:04:45 anonymous2 [Reply | View]
If you think Tcl's list and associated array are so powerful, you need to try a real scripting language like Ruby, Perl, or Python. Each of your points are also true for each of them.
Tcl survives for three reasons: Tk (still one of the most portable and ubiquitous GUIs), commercial CAD tools, and easy embedding.
The language itself is truly terrible. I cringe every time I have to touch it. -
What I hate about Tcl
2003-05-14 16:41:19 setok [Reply | View]
> The language itself is truly terrible. I cringe
> every time I have to touch it.
This seems like a horribly broad statement. As many of my friends know, Tcl is quit my favourite language by a fair margin. Not because of Tk or the associative arrays (I know other languages have them). What I truly love about Tcl is the way it doesn't limit how itself can be extended: it has a very simple syntax -- much simpler than almost any other language besides Lisp -- which can be extended in all sorts of directions with ease. There are no special cases or reserved keywords or static language constructs. I like to say "Tcl doesn't provide you with any programming paradigm -- you just [package require] the one you want".
Add to that the fabulous event-based IO, virtual filesystems, "everything-is-a-string" and a lush variety of OO possibilities (from [incr Tcl] to XOTcl and Snit) and it is difficult for me not to like what I see.
I hate to sound like I'm making a marketing pitch. I can accept that my points may not convince everyone, but your bold statement just made me see red and I do not believe it was justified in the slightest. If you wish to say something like that on a public forum, please offer us the courtesy of at least trying to explain your position. -
What I hate about Tcl
2003-05-14 12:25:21 sharkey [Reply | View]
"Truly terrible" is a bit of an overstatement.
It suffers from a commitment to overwhelmingly simple command syntax. All commands are "operator arg arg arg...", so instead of "$a = $b", you end up with the ugly "set a $b".
Simplicity is not always beautiful, but it does make embedding really easy. (in commercial CAD tools, tuxracer, network routers, or wherever)
And Tk rocks!
-
What I hate about Tcl
2003-05-14 16:45:14 setok [Reply | View]
> you end up with the ugly "set a $b".
I just tend to appreciate the beauty and power that kind of thing offers ;-) You can't have everything and logical simplicity is something that has always appealed to me, as a CS person. It's kind of funny too that people would complain about the above in Tcl, but don't complain about exactly the same thing in Lisp.
Ah well... RMS prefers Lisp so it must be brilliant?
-
What I hate..
2003-05-14 01:24:24 anonymous2 [Reply | View]
about Perl: "there's more than one way to do it" is best applied at a more abstract level (ie algorithm design) than coding -- maintainability is improved if the code is written the way the maintainer expects - "the naive way is the best way (tm)"
about Python: invisible syntactic elements
about PHP: silly inconsistencies
about Java: it's supposed to be universal, right? why no builtin types for decimal numbers and dates -- it's been estimated over half of programs have to deal with these (and many of the rest would be improved by using decimals instead of floats, IMO) PL/1 was better.
about visual basic: you've got to wonder about any language with "dim" as a reserved word. It probably has more inconsistencies than any three other languages put together.
-
url (wiki): "Why We Hate Perl"
2003-05-14 01:10:21 anonymous2 [Reply | View]
http://c2.com/cgi-bin/wiki?WhyWeHatePerl
-
And what do you think about ERLANG
2003-05-14 00:26:01 anonymous2 [Reply | View]
I agree and that's why I am now using Erlang ( www.erlang.org ;-) -
And what do you think about ERLANG
2003-05-14 09:59:45 anonymous2 [Reply | View]
Yeah, what he said. I'm a Scheme zealot working in a Java/C++ world, and have found Erlang to be a very nice practical compromise. Its combination of a strict functional [no side affects] core and asynchronous message-passing-based multi-processing is really powerful; you get the features you need for most client-server apps with the simplicity and clarity of functional programming.
What do I hate about Erlang? Record notation. I agree it may be useful for larger data-processing projects with different departments, etc. but 99 times out of 100 I just use a tuple because records are so UGLY.
-
What I hate about C++/C
2003-05-13 23:23:52 anonymous2 [Reply | View]
Garbage collection.
(Bill G. might add "buffer overflows")
-
OCaml for high level coding + good performance
2003-05-13 23:10:19 anonymous2 [Reply | View]
OCaml is one of the few languages I'd really like to get into - I already know quite a few languages ranging from C++ to Python and Perl. It is a very high level language that can run interpreted or compiled into machine code that rivals C for efficiency (and beats it on some benchmarks).
A modern Lisp has similar attributes and is probably better supported with tools and other infrastructure, but OCaml has a nicer syntax and seems to be evolving very fast.
-
Easier C extensions for Perl
2003-05-13 23:03:02 anonymous2 [Reply | View]
XS is the built-in way to extend Perl using C; however, the impressive Inline::* modules make it very easy to embed C, Java, Python and many other languages *within* a normal-looking Perl program. Inline::C is so easy to use that very few people should need to use XS.
-
Java: one thing I dislike about it
2003-05-13 22:55:30 anonymous2 [Reply | View]
Garbage collection. Not having to call free() is like not having to declare variables before they're used. It just promotes sloppy coding when a programming language encourages people to leave information out of the program (e.g. when an object is or should be freed).
-
Screw this! Why I love Prolog
2003-05-13 21:52:00 anonymous2 [Reply | View]
In Prolog you describe the problem instead of attempting to describe a (usually, accidentally, inevitably partial) solution.
This solves two problems at once: once the problem is understood, it is also (Zen-like) solved. -
Screw this! Why I love Prolog
2003-05-14 04:51:18 anonymous2 [Reply | View]
At best true for toy problems and if you're satisfied with O(n!) performance. There's quite a difference between:
randomsort(L1, L2) :-
permutation(L1, L2), ordered(L2).
and
quicksort([], []).
quicksort([X], [X]) :- !.
quicksort([H|T], S) :-
partition(H, T, L1, H2),
quicksort(L1, S1),
quicksort(L2, S2),
append(S1, [H | S2], S).
I like Prolog a lot, but the "describe the problem instead of the solution" claim is only partially true. Using it as the only reason to say you love Prolog mostly indicates that you should look for better arguments.
BTW: "Zen-like"? I think SLD-resolution is more responsible... -
Screw this! Why I love Prolog
2003-05-14 01:12:31 anonymous2 [Reply | View]
It doesn't scale, but - you've got to understand all of the problem all at once, or use various hacks to divide and conquer. Prolog is good if you're Marvin the Paranoid Android. -
Screw this! Why I love Prolog
2003-05-14 06:11:57 anonymous2 [Reply | View]
Prolog doesn't scale, but Mercury does ;)
I think that a lot of the benefits of programming in Prolog though are strongly linked to its interpreted nature and the way it lets you do things on the fly. Some of that dies when you move to a more hardcore statically typed lanugage like Mercury.
-
What I hate about RPG
2003-05-13 20:52:20 anonymous2 [Reply | View]
Having only 512 byte 'Session' area...
Having only 6 character Database Field references...
Having to chain several RPG programs together with CL/400... -
What I hate about RPG
2003-05-14 15:38:42 anonymous2 [Reply | View]
I hate RPG because it lets me access the database with incredible ease and allows me to generate cost effective code and allows me to generate cost effective code again and again.
I hate RPG because it helps me to think in processes and transactions.
I hate RPG because I can't talk for hours with my 'C' colleagues about 'performance' and how to squeeze another cycle.
(My last project was in C and I have had somuch fun hearing the buzzword 'performance' cut off all the corners for this project. Nothing is good except C. Please take me away from these 'performance queens'; they have twenty years of experience in C - and vanity. The project is not on time, doesn't deliver what was promised and will eventually be a write-off. In other words; just as people can have a licence but cannot drive so people can be experienced programmers in C (or else) and ... So does the type of language actually has anything to do with 'it' in a greater scope)
A language just expresses a solution, it isn't one.
I like Pascal, REXX, COBOL, RPG and C and probably any other one I will learn. -
What I hate about RPG
2003-05-14 09:41:22 anonymous2 [Reply | View]
Worst thing about RPG is the programmers that refuse to use any feature added to the language in the last 10 years.
You end up with monolithic programs that go on forever, all variables global, column based syntax that prevents indenting nested code (the free form syntax is just to radical).
Are real mess... -
What I hate about RPG
2003-05-14 07:47:14 anonymous2 [Reply | View]
I REALLY DONT NDRSTD PEOPLE WHO FIND IT DFFCLT TO EXPRSS THMSLF GIVEN CNSTRT OF SIX LETTRS. ANY DECENT RPG PRGRMR QUIKLY LEARNS HOW TO ABBRVT WTHOUT LOSING MEANNG. MY FIRST RPG INSTRC EXPLND THE FIRST DAY THAT RPG PRGRMS ARE SELF DCMTNG, AND MY YEARS OF RPG PRGMNG SUPPRT THAT CLAIM. THE SYS36 APRCHD PRFCTN! ANY PRGRMR WHO NEVER PRGRMD IN RPG IS NO PRGRMR AT ALL. WHO NEEDS RECRSN? WHO NEEDS LONG VARIBL NAMES? WHO NEEDS REUSBL CODE? IN RPG, WE GET INDCTR -- AND NOT JUST ONE, BUT NINTY9. IN RPG, WE GET LEVEL BREAKS -- AND WE GET TEN OF THOSE. WE GET PRIMRY AND SCNDRY FILES. BRNCHG BASED ON CALC SPEC RESULT INDCTR -- THATS REAL PRGMNG. FIELD LEVEL INDCTR ON THE INPUT SPEC -- THATS REAL PRGMNG. OH HOW I MISS THE BEAUTY OF RPG!
...about as much as I miss a festering wound...
-
What I hate about RPG
2003-05-14 03:55:26 anonymous2 [Reply | View]
Everything about RPG is wrong - and I had to use it for 8 years. Please lets not go there -
What I hate about RPG
2003-05-14 01:51:10 anonymous2 [Reply | View]
You meant in RPGII and RPGIII.
In the current version of RPGIV you can have much longer variable names,you certainly don't need CL 'to chain programs together.'
The best thing about RPG is that it runs on an iSeries with OS/400- it benefits from a rich environment. I don't think there are many banks that run on PERL, or C, C++ or any of the others mentioned. Thank f^%&^%.
-
What I Love About TCL
2003-05-13 20:06:53 anonymous2 [Reply | View]
It rules. Your perl/php sucks. Blah.
-
What I Hate About Wonks Who Ignore TCL
2003-05-13 20:05:28 anonymous2 [Reply | View]
Blah. Tcl rules for just about everything you wankers force perl or (ack!) php to do.
-
What do you hate about AspectJ?
2003-05-13 19:22:33 anonymous2 [Reply | View]
AspectJ might have been an interesting case. It supplies something like mixin's for Java by allowing inter-type member declarations on interfaces which are inherited by any class declared to implement the interface. Also, it surfaces the runtime model of interception (as Java might be said to have done with Threads/locks and the synchronized keyword). However, pointcuts can drag Java programmers back into regular expression land...
You use functionality as a rough equivalency test for programs, but they often differ most in the 'ilities, like robustness, portability, maintainability, integration, etc. (through the magic of re-use by libraries, frameworks, patterns, and so forth). So I guess an interesting question would have been what parts of the runtime model belong as API's or should get language-level support?
One answer is that a language should express the programmer's mental model, and automagically take care of things excluded from the programmer's model. The extreme example there, of course, is Visual Basic.
Finally, why do programmers like their languages? That could actually drive away from the principle of transparency towards the clubbiness and security of obscurity.
-
Dynamic Typing is good : Try Smalltalk
2003-05-13 19:21:29 anonymous2 [Reply | View]
Smalltalk was one of the first languages I encountered after BASIC and Pascal (yes, I encountered Smalltalk BEFORE I encountered C.) But I was a young programmer, and I let all the old C programmers talk me into accepting C for application development; after all, you really wanted a program that would run FAST!
What I like about Smalltalk is:
* relatively easy implementation. Like FORTH, you can create a core smalltalk VM and image in remarkably little code. Squeak (a free Smalltalk) was originally implemented in Smalltalk, automatically converted to C using Smalltalk code that converted Smalltalk to C, and then compiled for different platforms.
* integrated development environment. Yeah, I know, a lot of young punks will tell me I'm insane for liking Smalltalk's now antiquated looking IDE, but I really like the fact that I can modify the definition of a class while an application is running. I can debug it too!
* weak dynamic typing. Yes, some will say that this is evil. I think it is good. When programming in Smalltalk, I think about families of methods / messages, not types.
* complete source available. The development environment is integrated into the running image, so... you tend get the source for the complete environment (minus the C or assembly code for the primitives.) Some might say that this is bad as it allows "bad guys" to see your source code. Well.. you can actually ship an application without the source, but like Java, it will be difficult to hide your intent from a dedicated attacker.
What's not bad about Smalltalk
* speed. It's actually not that slow. Some tasks under Squeak are faster than Java. Java is faster for others. CinCom's commercial Smalltalk is faster than Java on just about everything.
* multi-person development in an IMAGE based environment. FORTH programmers will known what I'm talking about. Classic Smalltalk stores the complete state of all objects in object memory in an IMAGE. This is basically one big database of objects. For a long time, the big deal with IMAGE based systems was that it was difficult to separate the development environment from the running application. Proper use of changesets and Projects seem to have done a great deal towards fixing this.
* documentation. Depending on what you want to do, there may be enough documentation to get you started.
* online community. There's a Squeak Yahoo! Group that is quite active. Unlike Slashdot, most of the postings are not inane drivel.
What's bad about Smalltalk:
* Need delegation ala Objective-C. Smalltalk would be a lot cooler if if had delegation.
* need namespaces. There's primitive namespace support in some Smalltalks, but it should probably be a little bit better.
* polled I/O. The virtual machine running the Smalltalk image does polled I/O in classic Smalltalk (and in Squeak.) This is a bit of a disappointment, especially for embedded platforms.
* documentation. Sadly, there are some aspects to Smalltalk development that are less documented than they should be.
* mod_smalltalk is not ready for prime time. Yes, I should probably stop bitching and start helping, but I guess I'm currently content to watch from the sidelines. In the meantime, you can run Commanche in Squeak.
I'm not the only one to recommend fixing the top three problem areas with Smalltalk, but people in the community have pointed out that "it wouldn't be smalltalk" if we did this.
Still... Smalltalk is really, really cool. There are Smalltalk development environments available for multiple platforms ranging from Palms to Convexes, and everything in the middle.
If you're even the slightest bit interested, consider visiting the Squeak site at http://www.squeak.org/ or the Squeak SWIKI at http://minnow.cc.gatech.edu/squeak .
-
languages
2003-05-13 19:20:29 anonymous2 [Reply | View]
Eiffel is the best!!!
Static typing, dynamic binding, design by contract, multiple inheritance and genericity.
-
Why C Gets Used for Everything
2003-05-13 19:15:56 anonymous2 [Reply | View]
I don't know about C-style libraries being the lowest common denominator. C-style linkage is certainly easy enough to support in just about any language, but I've noticed a trend where newer technologies often don't have C libraries available for them. I attribute this to the difficulty of writing a complicated library in C. Sure, you can link it with just about anything, but writing the whole thing in C? You must be crazy.
Which brings me to my main point about C, and why I'm currently writing a network application in C :). C is the only really portable language (which is rather ironic, considering how easy it is to write non-portable C code). If you're writing the next Apache, you're probably going to write it in C, because such a fundamental bit of network infrastructure really has to be buildable everywhere, and you're only going to be able to get that capability with a C infrastructure.
Heck, just about every other scripting language has a C backend. The fact of the matter is, you can't write the interpreter for your next generation language in that language. It's a chicken-and-egg problem. Once you have the language up and running, it's convenient enough to build the libraries and such in that language, but the core is generally in C. That's actually the approach I'm taking with the application I'm writing. Right now, it's mainly an exercise in designing all the support infrastructure for a scripting language to run on top of.
-
Dynamic Typing is good : Try Smalltalk
2003-05-13 19:15:47 anonymous2 [Reply | View]
Smalltalk was one of the first languages I encountered after BASIC and Pascal (yes, I encountered Smalltalk BEFORE I encountered C.) But I was a young programmer, and I let all the old C programmers talk me into accepting C for application development; after all, you really wanted a program that would run FAST!
What I like about Smalltalk is:
* relatively easy implementation. Like FORTH, you can create a core smalltalk VM and image in remarkably little code. Squeak (a free Smalltalk) was originally implemented in Smalltalk, automatically converted to C using Smalltalk code that converted Smalltalk to C, and then compiled for different platforms.
* integrated development environment. Yeah, I know, a lot of young punks will tell me I'm insane for liking Smalltalk's now antiquated looking IDE, but I really like the fact that I can modify the definition of a class while an application is running. I can debug it too!
* weak dynamic typing. Yes, some will say that this is evil. I think it is good. When programming in Smalltalk, I think about families of methods / messages, not types.
* complete source available. The development environment is integrated into the running image, so... you tend get the source for the complete environment (minus the C or assembly code for the primitives.) Some might say that this is bad as it allows "bad guys" to see your source code. Well.. you can actually ship an application without the source, but like Java, it will be difficult to hide your intent from a dedicated attacker.
What's not bad about Smalltalk
* speed. It's actually not that slow. Some tasks under Squeak are faster than Java. Java is faster for others. CinCom's commercial Smalltalk is faster than Java on just about everything.
* multi-person development in an IMAGE based environment. FORTH programmers will known what I'm talking about. Classic Smalltalk stores the complete state of all objects in object memory in an IMAGE. This is basically one big database of objects. For a long time, the big deal with IMAGE based systems was that it was difficult to separate the development environment from the running application. Proper use of changesets and Projects seem to have done a great deal towards fixing this.
* documentation. Depending on what you want to do, there may be enough documentation to get you started.
* online community. There's a Squeak Yahoo! Group that is quite active. Unlike Slashdot, most of the postings are not inane drivel.
What's bad about Smalltalk:
* Need delegation ala Objective-C. Smalltalk would be a lot cooler if if had delegation.
* need namespaces. There's primitive namespace support in some Smalltalks, but it should probably be a little bit better.
* polled I/O. The virtual machine running the Smalltalk image does polled I/O in classic Smalltalk (and in Squeak.) This is a bit of a disappointment, especially for embedded platforms.
* documentation. Sadly, there are some aspects to Smalltalk development that are less documented than they should be.
* mod_smalltalk is not ready for prime time. Yes, I should probably stop bitching and start helping, but I guess I'm currently content to watch from the sidelines. In the meantime, you can run Commanche in Squeak.
I'm not the only one to recommend fixing the top three problem areas with Smalltalk, but people in the community have pointed out that "it wouldn't be smalltalk" if we did this.
Still... Smalltalk is really, really cool. There are Smalltalk development environments available for multiple platforms ranging from Palms to Convexes, and everything in the middle.
If you're even the slightest bit interested, consider visiting the Squeak site at http://www.squeak.org/ or the Squeak SWIKI at http://minnow.cc.gatech.edu/squeak .
-
Java + Exceptions
2003-05-13 17:44:49 anonymous2 [Reply | View]
Please illuminate me on when you would like to ignore an exception.
-
Java + Exceptions
2003-05-14 01:51:55 anonymous2 [Reply | View]
You can ignore them. Just say
void blabla(blabla) throws AnExceptionIWantToIgnore {
moreblabla
}
and you can ignore the exception inside "moreblabla" ... -
Java + Exceptions
2003-05-14 08:52:08 anonymous2 [Reply | View]
That isn't what the author (or others) are advocating.
void foo()
{
try
{
}
catch(IOException ex)
{
throw new RuntimeException(ex);
}
}
Now you can totaly ignore it.
This is a terrible way to program.
-
Java + Exceptions
2003-05-14 09:44:13 anonymous2 [Reply | View]
Actually what the author and others are defending is that you can do this:
voif foo() {
// ...
}
and if an exception is raised, it goes up to where is caught, or thrown to the toplevel.
C++ expections are this way, you don't have to declare which exceptions can foo() trow, and it's actually Bad to do so, except when you want to guarantee the compiler it throws none (example: destructors:
MyClass::~MyClass() throws ()
{
// destructors *cannot* throw or Really Evil Things will happen
}
any other exception spec is discouraged, they aren't optimization hints, nor actually document the exceptions that can be thrown by a function: libraries can throw their own exceptions, without limitations...)
best regards, -
Java + Exceptions
2003-05-14 10:51:38 chromatic |
[Reply | View]
Yep, that's what I mean. I don't consider having to say "by the way, this method doesn't want to catch an exception, so it's going to throw it up the call stack" to be "ignoring" an exception.
In general, I'm not a fan of writing code to tell the compiler to do nothing. Sometimes I want to ignore FileNotFound -- it's okay, I know what I'm doing. -
Java + Exceptions
2003-05-15 02:03:11 anonymous2 [Reply | View]
No you clearly do not know what you are doing. The whole point of checked exceptions is that the compiler can help verify that you are not forgetting to handle them.
You have to catch the FileNotFoundException somewhere... might as well make the code clear as to what is going on.
If you are happy to have your program exit with a stack trace... then you really really do not have a clue as to what you are doing.
-
Java + Exceptions
2003-05-15 10:11:33 chromatic |
[Reply | View]
Yes, that's exactly my gripe.
If I don't think a missing file is an exceptional condition within the current program, I don't really have the option to ignore FileNotFoundException. I either catch it explicitly or let it propogate upwards and crash with a stack trace.
I'd like to be able to ignore (as in, "not have to write any code to tell the language not to do something") certain exceptions sometimes. I don't have that option in Java, unless I do a bit of metaprogramming or rethrow exceptions as run-time exceptions, or some other technique.
The problem with a mandatory, checked exception system is that what Sun thinks are exceptional conditions are not always what I think are exceptional conditions in certain situations. -
Java + Exceptions
2003-05-15 15:22:48 anonymous2 [Reply | View]
You are missing the point - a user should never see a stack trace. If you think missing the file is a good time to bail on the program than catch it and do a System.exit.
If you are selectivly able to ignore exceptions you wind up either missing important cases or writing catchal (like ... or Exception) and handling exceptions it a totaly wrong manener.
You should not be using exceptions to automagically end the program - that is the height of lazyness. -
Java + Exceptions
2003-05-15 15:40:59 chromatic |
[Reply | View]
No.
All I'm saying is that sometimes I don't consider certain things exceptional. Java won't let me ignore them. I either have to deal with the exception or let it crash.
I don't like either option. If I know the file's not likely to be there and my program isn't going to crash if it's not there, it's not an exceptional condition. Why do I have to do busywork to make my intent clear? -
Java + Exceptions
2003-05-15 16:42:08 anonymous2 [Reply | View]
Why would you open a file for reading if you don't think it is going to be there?
If you ask to open a file and it does not exist then, yes, it is an exceptional condition.
Also if you wrote the code in, say, C and you didn't check the return of fopen you would "need" to put a comment to make the intent clear. Why put a comment that can easily be wrong after modifying the code if the compiler can do it for free?
Also if you open a file AND it doesn't exist you would need to check that the return value was not null... messy boilerplate code that is easy to get wrong and hides the logic of the program.
Please give a clear, concise, somewhat complete example of what you are saying you want - to open a file that may/may not exist and have it be fine either way AND detail what you would rather go through than deal with exceptions.
-
Java + Exceptions
2003-05-15 22:25:54 anonymous2 [Reply | View]
What the other guy wants is supported in other languages. I won't tell you which as you might criticize the language just because of that:). There are cases that you may just want to ignore an exception. The language I know well just has you 'flick a switch' before executing the code and that code will run just as it would have executed OK even though the results may vary.
Basically the switch stops any (or most) errors from percolating from the system into your function. Some systems are very explicit with their messages so I may have to catch say 20 exception messages to have the function 'continu'.
Another ''envvar'' may later be tested if something went wrong indeed if you want to - and did not reuse that ''envvar''.
So if I open a file - which can go wrong for maybe a hundred reasons with a dozen error codes on this system - a can flick the switch and later test whether it was successful or not - which is the only thing I am interested in. (In this case I am still handling the exception, I know.)
This is obviously not Java, but it makes me understand the question.
-
Dynamic typing is evil
2003-05-13 17:39:52 anonymous2 [Reply | View]
Once upon a time I tried the "rescue" option of my Red Hat install CD, only to have Anaconda installer script barf on me with a Python traceback saying that the object "_" didn't have a toString method (or something to that effect). That's when I decided dynamic typing was evil.
Later on I wrote a big app in Java, but every time I wanted to distribute it, I had to ask people to mess about with interpreters and libraries. Even then there were lots of platform/implementation dependant issues. That's when I decided interpreted languages were impractical.
So now I'm back to C. And I love it :) -
Dynamic typing is evil
2003-05-14 04:04:43 anonymous2 [Reply | View]
"Later on I wrote a big app in Java, but every time I wanted to distribute it, I had to ask people to mess about with interpreters and libraries. Even then there were lots of platform/implementation dependant issues. That's when I decided interpreted languages were impractical."
There are various methods available that package a Java application together with a VM and all the classes it depends upon into a single executable file. Some of these compile to native code (eg the gnu java compiler, available as part of gcc 3), others merely package class files and VM together. These solve the problem you talk about.
-
Another C Nitpick
2003-05-13 17:00:40 anonymous2 [Reply | View]
<quote> Quick, what are the differences between execl, execlp, execle, execv, and execvp? If you're not using these every day, you'll be hitting man 3 exec often.</quote>
If you aren't using these every day, you won't be hitting man 3 exec that often!
-
Another C Nitpick
2003-05-13 18:56:10 anonymous2 [Reply | View]
The issue I have with this statement is that exec and friends aren't part of the C standard library at all--they're part of UNIX (or if we're talking about real standards, POSIX).
I personally just use exec() and skip all the other variants (which are mainly just prettification), but this is really only something that *NIX programmers have to deal with (similarly with the crypticness of the variants on the name exec). You're definitely not going to find exec() and its umpteen variants named as such in the Windows API. So it's really not a valid critique of C at all, but of UNIX.
-
Language common to all Programmers ...
2003-05-13 16:56:48 anonymous2 [Reply | View]
Profanity
:-)
-
C...
2003-05-13 16:26:25 anonymous2 [Reply | View]
Objective-C is nice, has dynamic binding, has additional ways of getting around not having multiple inheritance (if that's a feature you want) in addition to protocols (interfaces in Java). And the Openstep, GNUStep, and Apple frameworks are a fantastic base to build on.
http://www.geom.umn.edu/software/w3kit/overview/objective-c.html
http://www.swarm.org/resources-objc.html
-
Objective C
2003-05-13 16:22:04 anonymous2 [Reply | View]
Knowing C, Java, Scheme, Perl, and Objective C, I'd have to say that Objective C really is among my favorite languages, precisely because of its hybrid nature. Things I like:
* You can do strong typing, but you don't have to.
* You can extend the functionality of classes (with extra methods) without needing the original source of the methods (using Categories).
* Messaging nil has no ill side effects as long as you don't rely on the return value of your method.
The only major complaints I've ever heard are the lack of class variables (which you can work around by using static globals in your class implementation file), and the lack of private methods (which you can work around by not advertising your methods in your header file). A few people bitch about no automatic garbage-collecting, but I see this is a feature, not a bug.
Other than that, I think it's syntactically nice, promotes readable code by using infix notation for method calls, and is a true superset of C (unlike C++). Also, the small number of syntactic element s that are added makes it an even bigger plus, since it really only takes an afternoon to learn! -
Objective C
2003-05-13 16:51:56 anonymous2 [Reply | View]
The problem with Objective C is that there is no "Objective C". What you're describing is gcc Objective C (or possible Apple Objective C), which is only half of "Objective C".
POC follows from Stepstone style Objective C and differs in a number of ways. First of all, automatic garbage collection (in the forms of automatic reference counting and Boehm) if you want. Secondly, honest to God actual closures (called blocks for some reason). Thirdly, rather simplified: no static typing of objects (can be annoying in spots), no protocols, etc. Fourthly, class variables (yay). And finally, the run-time is much much MUCH nicer than Foundation Kit IMHO.
Apple Objective C and POC Objective C come from drastically different families. Their run-times and syntaxes follow different philosophies (Apple seems to be a C++/Java wannabe; POC is a Smalltalk wannabe to the highest degree). It's hard to consider them the same language sometimes.
Anyway, no point to this message at all, except that I hate people equating Apple/GNU Objective C with "Objective C". There are other Objective Cs!
-
Haskell
2003-05-13 16:18:53 anonymous2 [Reply | View]
Definitely learn Haskell if you want to get a look at a very strongly-typed language. It's also a pure lazy functional language, which is great for broadening the horizons (not many functional languages are as obsessively pure as Haskell).
Sure, the typing system can get really irritating at times, but after a while I found it very useful for catching bugs at compile time instead of runtime - if the types don't match, often it means you're attempting to do something that you shouldn't be doing.
If you are going to learn Haskell though, make sure you learn about monads. They're absolutely invaluable. -
Haskell
2003-05-13 23:38:01 anonymous2 [Reply | View]
Cynical thought. What's funny is when COBOL first came out it advertised largely the same benefits. Quoting from Haskell.org:
* Substantially increased programmer productivity (Ericsson measured an improvement factor of between 9 and 25 in one set of experiments on telephony software).
* Shorter, clearer, and more maintainable code.
Fewer errors, higher reliability.
* A smaller "semantic gap" between the programmer and the language.
* Shorter lead times.
-
Haskell
2003-05-14 10:19:08 anonymous2 [Reply | View]
That's dumb. Yes, COBOL advertised those benefits, but, WITHIN ITS INTENDED DOMAIN (fixed-structure record-processing) there're very few languages that can touch it. COBOL is very good at what it's designed to do; the fact that it's original purpose is largely obsolete doesn't translate their claims into a counterargument against Haskell (or anything else for that matter).
-
variable contexts in perl
2003-05-13 16:04:17 anonymous2 [Reply | View]
why do I have to tell the language whether I want an integer or not? Being able to reference arrays in scalar context and references in hash context means that complex data structures with more than one level of reference are a nightmare to work out exactly which combinations of $ and -> and { you need to reference the data you want.
-
variable contexts in perl
2003-05-14 01:43:22 anonymous2 [Reply | View]
Ugh because numbers in Perl are floating point by default. If you read perldoc perlop and perldoc integer you'd see this. As for references, sounds like you lack the knowledge. Anybody who learsn references in Perl knows how to dereference them. If you can't figure out how to dereference or when to, then you shouldn't be playing with references let alone worrying about how to defrerence. Sounds like you don't know about design, while Perl code can get ugly it's still easy to design good code. As for readability, http://perltidy.sf.net.
-
Graphical Programming
2003-05-13 15:57:50 anonymous2 [Reply | View]
The article doesn't mention the ease/difficulty of programming in a Graphical language ex. LabVIEW. I used to hate it till I started using it. Now I do almost everything in LabVIEW.
What I Hate about it?
+ It ain't free.
+ No recursion
+ No OOP
+ Expensive toolkit add-ons for special functionality (Signal processing, Real-time etc.)
+ No matrix data-type. Of course you can use arrays but I would like to see a Matrix primitive
What I love about?
+ Takes me a day to do a project which I would
normally take a week to do in C.
+ Elegant and self explanatory
+ Dataflow programming style.
+ Great debugging tools
-
Graphical Programming
2003-05-14 18:25:58 setok [Reply | View]
One additional thing worth considering with graphical programming is that it's the most natural thing in the world to make a multi-threaded application... -
Graphical Programming
2003-05-14 04:24:03 anonymous2 [Reply | View]
Actually there are toolkits available for OOP in LabVIEW. I would like to recommend you to look at www.endevo.se for a product called GOOP (Graphical Object Oriented Programming). A new release that also supports inheritance is due later this year. -
Graphical Programming
2003-05-13 18:45:27 anonymous2 [Reply | View]
In the interest of having some LabVIEW gripes, here's mine in addition to those above:
- Complex things are harder to code in LabVIEW than in a textual language.
- Very slow at matrix things when you do try to kludge it in. I agree, it desperately needs a matrix primitive (other than multi-dimensional arrays).
-
What You Hate About C++
2003-05-13 15:25:18 anonymous2 [Reply | View]
/I find the template syntax ugly. I have no idea how to make it more beautiful, though./
For a general deuglification of C++ see:
http://www.csse.monash.edu.au/~damian/papers/PDF/ModestProposal.pdf
Of course, like all such proposals, this one was not well received. ;-)
Damian
-
A few miscellaneous comments
2003-05-13 15:21:44 anonymous2 [Reply | View]
Java does have the ability to do unchecked exceptions. It only checks exceptions derived from "Exception"; unfortunately this doesn't help when you want exceptions thrown by other people's code (like the standard library) to be unchecked.
I was impressed to find out that javascript has closures, whatever its shortcomings are.
I've noticed that while XSLT was designed to be programmed in a functional manner, very few implementations have tail call optimization.
-
Learn Common Lisp
2003-05-13 15:19:25 anonymous2 [Reply | View]
The ultimate dynamic language--superb object system with incredible introspection facilities through the MOP, good commercial compilers (www.franz.com, www.lispworks.com, www.scieneer.com), good free compilers (www.cons.org/cmucl), the speed benefits of a typed language (if you use type declarations and declare the appropriate optimization level), the ability to patch running programs, first-class closures, hash-tables, lists, arrays, strings, etc., numbers never over flow, and so much more... The only thing to hate is that relatively few people truly know it. -
Learn Common Lisp
2003-05-14 07:39:06 anonymous2 [Reply | View]
I agree that CL is very good. It's my first choice for most programs, and I'm familiar with a lot of choices.
CL has one unusual strength that the earlier poster didn't mention: the syntax of CL programs ("Lots of Infernal Stupid Parentheses") makes it extremely easy for CL programs to manipulate CL program source as data (correctly, and without writing a parser). This makes program-writing programs extremely easy to implement. Even lowly one-liner macros end up being much more powerful and useful in CL than one would expect from experience in other languages, and more advanced uses are startlingly powerful. (One common example is to write one's own object system -- inheritance, polymorphism, encapsulation -- from scratch. It's easy to do this in a page or two of CL code, and before CLOS was standardized, it was quite common.)
CL is not perfect, however. It suffers from the usual library weakness of languages with small user communities. The flipside of its dynamic nature -- things like the aforementioned ability to patch running programs -- is that there are various correctness checks and performance optimizations that the compiler can't make. It's pretty efficient, with good native compilers, but for various reasons (including GC and dynamic typing) it can sometimes be anywhere from annoying to impossible to get the last factor of two in portable performance relative to C/C++. And it's a fairly big language, which is pretty common and mostly uncontroversial these days, but which still provokes some friction with people who want something more like the austere elegance of Scheme.
CL also has the weaknesses and strengths of an old language, since it has evolved since the 60s and since it was standardized starting in the 1980s. These weaknesses include various warts in its design (for backwards compatibility or because design tradeoffs looked different in 1987). The strengths include having gotten a lot of things right long ago, like GC by 1970 (?) and lexical closures by the mid-1970s. (It has been sort of interesting watching the semantics of other languages like Perl and Python recapitulate the evolution of Lisp toward GC and lexical closures.)
So for small stable systems where microefficiency is a big issue, I might prefer C or C++ instead; for some things where ML's static type checking model is a good fit I might prefer ML instead (so e.g. I have no trouble understanding why many compiler writers like ML); but mainly I prefer CL. When I don't use CL the usual reason is that I'm working on a problem where suitable libraries or legacy code already exist in another language but not in CL.
Incidentally, for even more free Lisp resources, see www.cliki.net.
-
Learn Common Lisp
2003-05-14 07:16:23 anonymous2 [Reply | View]
You forgot one thing: macros! To the programmers of other languages the word "macro" probably brings to mind something quite different. But lisp macros are an incredibly powerful abstraction tool. -
Learn Common Lisp
2003-05-13 20:17:04 anonymous2 [Reply | View]
I have to second this recommendation. I have not been fortunate enough to land a job writing in Lisp, but I regularly use it from within Emacs. More importantly, if you can understand the similarities between Paul Graham's book On Lisp (http://www.paulgraham.com/onlisp.html) and Andrei Alexandrescu's Modern C++ Design (http://www.moderncppdesign.com/), you are ready to program in any language.








http://musiclessonz.com/rebol_tutorial.html