Why do you prefer [n] programming language?

[evilbeanfiend]

I'd like to push Inform 7.

ooh good choice, its a very good DSL, also iirc a lot of the language is defined using itself, this isn't that revolutionary in itself (plenty of other language are basically large libraries built on a few language rules e.g. tcl) but given the nature of inform it makes it a really good read.

[aleflamedyud]

I think the language you're looking for is boo. It has a Python-like syntax, though it's statically typed, and you don't have to specify the static type, as they're automatically deduced. You can also use it as a scripting language. The only difference is that it runs in the CLI, but that has benefits, such as being able to interact with the other CLI languages and getting all the speed improvements of the just-in-time compiler. Should be as fast as C#. Generics aren't in yet, but that's the next milestone. (I won't personally use it until they're introduced.)

Let's see... garbage-collected VM that requires a whole damned operating system and framework to run a Hello World program? CHECK! BOOOOO to Boo!

What part of "bare metal" is not being understood here?

[Hangar]

CLI languages do not run in a VM. They're always compiled natively just before being run. And garbage collected languages can be faster than those with explicit memory management. See this article for the argument: http://www.digitalmars.com/d/2.0/garbage.html

As for requiring an OS and framework to run, C requires an OS to run, no less complex than the OS that Boo or C# requires (something has to provide malloc). The framework on the other hand is a deviation from your requirements. Mono is portable and is getting really close to implementing all of .NET 2.0, so portability isn't the concern here.

The bad part is having to require the framework with your programs, but the framework is more and more widely distributed. It's a value judgment, but I believe the pros outweigh the cons there. You get so many features such as language interoperability, universal binaries, security and reflection if you need them.

The other deviation is that CLI languages are compiled just before running them instead of compiling them ahead of time. This means that a lot of CPU-intensive traditional optimizations aren't applicable, but I hope to see this rectified in the future. I don't know that the real gains can come from initially compiling from the language to the CLI byte code, but I think the byte code represents CLI languages pretty well, so there should be room for a lot of optimization going from byte code to machine code. I hope that more intensive precompilation becomes the norm.

Anyway, don't knock it until you try it. Slight speed losses are nothing compared to these giant gains in programmer productivity. I only wish Monodevelop was more mature.

edit: Ignore that last part about Monodevelop. Just checked and apparently it's my distro. I should compile from source.

[Kirby54925]

I agree with Hangar. I really don't see what all the obsession of running code "close to the bare metal" is about. From a pragmatic perspective, the only two uses I see for those types of languages are if you are writing relatively small programs that does one thing and one thing very well and very quickly (UNIX philosophy) and if you are writing programs that have to interface with specific hardware, such as drivers. But if you are writing a program that doesn't have to rely on speed, such as for instance a program that is used for Swiss-style tournaments or a program that handles elections and supports different election methods, writing it in a higher-level language would make more sense, right? Rather than falling into the trap that programmers have to express their problem in terms of the way the computer sees things, we must express the program in terms of the problem at hand. Not only will this increase programmer productivity, but it will also reduce code complexity.

[Hangar]

It's a big concern for me, since I mostly do games. The point is, CLI languages do run pretty close to the metal, at least close enough for games, which are some of the most intensive applications out there right now. I started looking at the language D after running into some problems interfacing between C++ and garbage-collected Lua. But while D looks good in theory, CLI languages are ready for use and deliver what they promise.

[EvanED]

A couple comments on the D page you linked.

One benefit they didn't mention speedwise is that memory allocation in a GC'd language is extremely fast. Something like the following:

Code: Select all

char* first_free = BEGINNING_OF_HEAP;
void * malloc(size_t size)
{
    void* memory = first_free;
    first_free += size;
    return memory;
}

(You may need to increase the allocation size a little and store amount, etc.)

Whereas in C, you need to run some algorithm to find memory. First fit/worst fit, some fancier algorithm, etc. (GNU malloc has a couple different algorithms and a couple different pools depending on the allocation size.)

At the same time, the time to run GC is proportional to the number of live objects, not the total number of objects; the time to deallocate in C is proportional to the number of allocated objects.

What this boils down to is that if you have lots of short-lived objects, the quick allocation time and zero deallocation time can actually help your performance.

Another benefit they didn't mention is that if your program is short-lived, the GC probably doesn't even need to run, and you can just let the OS release your memory when it's done.

In response to your "Let's see... garbage-collected VM that requires a whole damned operating system and framework to run a Hello World program?" comment I almost posted "how many Hello World programs do you write?" but then thought better of it, because there are MANY short-lived processes, especially if you work in the Unix philosophy of often connecting seventeen different programs together from the command line. But either your program is short-lived or it's not: if it is short-lived, then the fact that it's garbage-collected is almost certainly a good thing performance-wise. And if it will stick around for a while, then the startup time is negligible.

[aleflamedyud]

C requires an OS to run

No it doesn't. You can compile a C program with a "freestanding" switch that doesn't link any kind of standard library or operating-system interface in and it will work fine. This is how operating systems and drivers are written.

Now what if I wanted to write one of those two things in a language that doesn't suck? Well then I wouldn't want a CLI or a GC, would I?

[Kirby54925]

C requires an OS to run

No it doesn't. You can compile a C program with a "freestanding" switch that doesn't link any kind of standard library or operating-system interface in and it will work fine. This is how operating systems and drivers are written.

Now what if I wanted to write one of those two things in a language that doesn't suck? Well then I wouldn't want a CLI or a GC, would I?

So wait a second... you intend on writing an OS or device drivers, or are you planning on writing some utility programs (by utility, I mean any program where you don't need to know how the damn system is implemented in order to code it, such as a web app or an implementation of an election method)? If it's the former, that is fine because you are basically reinforcing my original belief that all a low-level language is good for is writing programs that have to "talk" to hardware at the near-primitive level. If it's the latter... then you must really like writing low-level code to do high level things, which is not necessarily a bad thing, but it does waste your time and increase code complexity.

[aleflamedyud]

I want a high-level, capable language in which to write device drivers and operating systems. It's been 30 years since the invention of C, which made practical compromises on its feature-set to suit its own era. Why do we still use such a godawful language in our most fundamental software?!

Dear Lord, why would I write something so boring as a web app?

[coppro]

I want a high-level, capable language in which to write device drivers and operating systems. It's been 30 years since the invention of C, which made practical compromises on its feature-set to suit its own era. Why do we still use such a godawful language in our most fundamental software?!

Dear Lord, why would I write something so boring as a web app?

C++ can be used in the same way (as a freestanding implementation). Some people will tell you not to use stuff like exceptions or templates in freestanding implementations, but the standard requires that a freestanding implementation be identical in most regards - the major exceptions being the availability of libraries and the way the program starts up.

There's even a new standardized asm keyword in C++0x!

[aleflamedyud]

Oh, I know. It's just that when you actually try to build a free-standing version of C++ you run into sheer hell because every compiler codes its run-time library differently, and the new, delete, and = operators actually require a malloc implementation in there somewhere to work.

Trust me, I've tried C++. Its ability to run freestanding was kept as a sort of homage to C, but it's not really designed to run that way. Also, you have to bolt on the functional features and neater typing systems via templates and macros which, while they form a Turing-complete programming language, do not form a neat or simple way to accomplish the desired goals.

Though I agree that adding an inline-asm keyword into C++0x is a good idea. Other high-level languages have had that for years.

[Kirby54925]

The web app thing was just something I thought up on the spot that's not involving OS/drivers . Obviously, I can think of better things to program. In fact, in order for me to learn Common Lisp, I am trying to code up a Swiss system tournament program that can be used for any type of game besides chess. Those programmers specialize too much on chess -- which includes hard coding algorithms for color selection, which I really want to make optional in my program -- and don't do enough to generalize to any activity that requires a tournament.

Anyway, now that you made your intentions (as in what kinds of stuff you like to program) clear, I can't really comment on them, as I am not interested in coding OSs and drivers. I will still say I dislike languages that work on such a low level because it hinders my ability to code my programs in terms of the problem(s) I am trying to solve, and I rarely have to deal with doing micro-optimizations (I am a firm believer that algorithm choice has a much bigger effect on running time than silly trickses that usually only net gains within constant factors).

To conclude (and to directly answer the topic of this thread), I prefer Common Lisp (even though I am a newbie at it!) because its syntax is very simple compared to languages with C-like syntax; however, once Python 3.0 comes out later this year, I might take some time to learn it as well because its libraries are far more vast than any individual Common Lisp implementation's.

[qbg]

I want a high-level, capable language in which to write device drivers and operating systems. It's been 30 years since the invention of C, which made practical compromises on its feature-set to suit its own era. Why do we still use such a godawful language in our most fundamental software?!

Dear Lord, why would I write something so boring as a web app?

You could bring the lisp machines back...

[Kirby54925]

Ooh, nice idea! Are they the ones made by Xerox's PARC back in the day?

[qbg]

Another reason for Common Lisp:

Code: Select all

#1=(defun quine ()
        (let ((*print-circle* t))
          (print '#1#)
          nil))


[zenten]

The web app thing was just something I thought up on the spot that's not involving OS/drivers . Obviously, I can think of better things to program. In fact, in order for me to learn Common Lisp, I am trying to code up a Swiss system tournament program that can be used for any type of game besides chess. Those programmers specialize too much on chess -- which includes hard coding algorithms for color selection, which I really want to make optional in my program -- and don't do enough to generalize to any activity that requires a tournament.

Anyway, now that you made your intentions (as in what kinds of stuff you like to program) clear, I can't really comment on them, as I am not interested in coding OSs and drivers. I will still say I dislike languages that work on such a low level because it hinders my ability to code my programs in terms of the problem(s) I am trying to solve, and I rarely have to deal with doing micro-optimizations (I am a firm believer that algorithm choice has a much bigger effect on running time than silly trickses that usually only net gains within constant factors).

To conclude (and to directly answer the topic of this thread), I prefer Common Lisp (even though I am a newbie at it!) because its syntax is very simple compared to languages with C-like syntax; however, once Python 3.0 comes out later this year, I might take some time to learn it as well because its libraries are far more vast than any individual Common Lisp implementation's.

Odd, I thought device drivers and OSes could be written in LISP.

[Polaris]

You forgot to mention Smalltalk in the OO list, which I find odd, considering it is the most "pure" OO language, and was originally designed with the beginner in mind. That said, I probably wouldn't recommend it, as it has never been well-implemented, and it gives an extraordinarily skewed view of programming.

I can write Smalltalk and there's a good reason why I didn't mention it.

And I'd love to see how Smalltalk is more "pure" than C#. Don't tel me structs aren't objects, because they are; many people who are ill-informed of the inner workings of the CLR and how C# writes IL tend to say "C# structs = java primitives," which only shows their ignorance - even System.Type derives from Object.

[quintopia]

You already know why smalltalk is more "pure." Namely, that everything must be treated as if it is an object, and no action can be completed that does not require sending a message to an object. C# still has different syntax for dealing with primitives, and the fact that "boxing" and "unboxing" exist show this. In Smalltalk, even the lowliest number is an object (as far as the user can tell), and must be interacted with by sending it messages.

[EvanED]

You already know why smalltalk is more "pure." Namely, that everything must be treated as if it is an object, and no action can be completed that does not require sending a message to an object. C# still has different syntax for dealing with primitives, and the fact that "boxing" and "unboxing" exist show this. In Smalltalk, even the lowliest number is an object (as far as the user can tell), and must be interacted with by sending it messages.

Not just numbers... the freaking if "statement" is an object!

[zenten]

You already know why smalltalk is more "pure." Namely, that everything must be treated as if it is an object, and no action can be completed that does not require sending a message to an object. C# still has different syntax for dealing with primitives, and the fact that "boxing" and "unboxing" exist show this. In Smalltalk, even the lowliest number is an object (as far as the user can tell), and must be interacted with by sending it messages.

Not just numbers... the freaking if "statement" is an object!

Well, that's true for Python as well.

I think to decide "What language is more OO" you first have to figure out what you mean by that. Is a language where there are non-object primitives that get treated like an object (such as arrays in Java, but pretend everything is like that) more or less Object Oriented than a language where everything is an object but is often not treated as such (such as Python).

[EvanED]

You already know why smalltalk is more "pure." Namely, that everything must be treated as if it is an object, and no action can be completed that does not require sending a message to an object. C# still has different syntax for dealing with primitives, and the fact that "boxing" and "unboxing" exist show this. In Smalltalk, even the lowliest number is an object (as far as the user can tell), and must be interacted with by sending it messages.

Not just numbers... the freaking if "statement" is an object!

Well, that's true for Python as well.

Yeah, but not for Java, C#, or C++, which is what Polaris gave as examples of what to learn for OO languages.

(This conversation thread is lost a little across threads; it started here.)

[ash.gti]

The fundamental differences between C++ and Smalltalk in terms of their 'pureness' of OO could also be judged by the fact that C++, Java, Python, PHP, Perl, etc. were all Imperative programming languages at their core originally and then the designers of the language started adding in OO aspects because it seemed like a good idea.

Smalltalk, Ruby were designed purely based on OO from the get go.

Thats why in those two languages primitives 'technically' don't exists.

Most languages even after they have evolved into what they are today started out as a single paradigm language that was either designed to be a 'better'* version of something else.

* Where better could mean faster, more dynamic, scripted, etc. *

Very few languages today are only capable of one paradigm but for all of them you can trace their syntax and structure back to a single root.

[Berengal]

Something I've wondered a bit about is; is there a language where it's impossible to write imperative programs? All languages I've seen have the capability to write statements that change depending on the order they're executed in.

[zenten]

Something I've wondered a bit about is; is there a language where it's impossible to write imperative programs? All languages I've seen have the capability to write statements that change depending on the order they're executed in.

I'm pretty sure some types of Lisp fit your requirement.

[ash.gti]

Something I've wondered a bit about is; is there a language where it's impossible to write imperative programs? All languages I've seen have the capability to write statements that change depending on the order they're executed in.

I'm pretty sure some types of Lisp fit your requirement.

As does Smalltalk

All functions have to be bound to an object, so there is no way to have any sort of 'global' functions.

[Berengal]

Java also requires that all functions are part of a class. This just means you have to wrap your imperative program in a class. A single call to main is still all that is required. I haven't tried smalltalk, but I suspect something similar can be done.
As for lisp,

Code: Select all

(defun imp() (print "First!") (print "Second!"))

This is imperative, no? I realize coding this way in lisp is incredibly painful, but it's not impossible.

[Xanthir]

Something I've wondered a bit about is; is there a language where it's impossible to write imperative programs? All languages I've seen have the capability to write statements that change depending on the order they're executed in.

I'm pretty sure some types of Lisp fit your requirement.

Lisp has been imperative-capable for a long time. You could make an entire program just using (setf) and (print) and such, with nary a (let) or closure in sight. You'd be dumb to do so, but still.

Um, prolog?

[zenten]

Something I've wondered a bit about is; is there a language where it's impossible to write imperative programs? All languages I've seen have the capability to write statements that change depending on the order they're executed in.

I'm pretty sure some types of Lisp fit your requirement.

Lisp has been imperative-capable for a long time. You could make an entire program just using (setf) and (print) and such, with nary a (let) or closure in sight. You'd be dumb to do so, but still.

Um, prolog?

Sure, most versions of Lisp are imperative-capable, but not all.

And I was taught Prolog in an imperative manner in my Prolog class. It made me wonder why I was bothering with it, as backtracking seemed tacked on and something that would fit just as well in a more traditional language.

[quintopia]

Unlambda makes imperative programming extraordinarily difficult, although I couldn't tell you whether or not it's possible.

So, I've had some time to think about this, and here's my opinion:

For the sheer fun of the cool stuff you can make: Processing. (Although, I'd use it more if there were a well-documented and easy to use controller interface, as controlP5 just sucks. . .you can't even get text out of a text field unless the user hits enter. I'm sure someone is working on this, though.)

For the beauty of the language itself: Smalltalk (Although I don't enjoy coding in it as much as I would, because, as I said in the other thread that was quoted here, I don't think it has been well-implemented.)

For the fun of solving difficult problems with simple tools: any tarpit where instructions are assigned to single ascii symbols.

[xyzzy]

Haskell would probably do it, something about lazy evaluation.

[Hangar]

Lots of older pattern-matching languages would match the description. Mostly for writing queries into sets of data.

[levicc00123]

I think the language you're looking for is boo. It has a Python-like syntax, though it's statically typed, and you don't have to specify the static type, as they're automatically deduced. You can also use it as a scripting language. The only difference is that it runs in the CLI, but that has benefits, such as being able to interact with the other CLI languages and getting all the speed improvements of the just-in-time compiler. Should be as fast as C#. Generics aren't in yet, but that's the next milestone. (I won't personally use it until they're introduced.)

Another vote for Boo, python-like syntax, access to the .NET CLI, and a lot of extra items that aren't in python.

[BlackSails]

Java! Because its the only one I know.

(Yes, I hang my head in shame. Ok ok, I know a small amount of python)

[Ptolom]

I prefer C++ becuse it's awesome.
Now that's a logically justified opinion

[headprogrammingczar]

wouldn't every language need to be imperative at some point? Without an imperative form, the program is time independent, and therefore cannot cause a change over time. In which case, why the hell did you write the program anyway?
EDIT: To stay on topic, I prefer Java, because it consistently does what I expect without the hoops I have seen in other languages (search the coding forum for Java help threads; there are only five). For math scripts, I use TI-83 BASIC, because that language was written in math.

[TheGZeus]

I like Lisps because you start out with what's needed (or more, but you don't have to use CLOS, readers...) and can add more. Also, a single function can run alone, lets me test as I go, even if I'm not done with anything useful.
Tcl looks pretty interesting, too.

wouldn't every language need to be imperative at some point? Without an imperative form, the program is time independent, and therefore cannot cause a change over time. In which case, why the hell did you write the program anyway?

What you write and what runs are two different things.

EDIT: To stay on topic, I prefer Java, because it consistently does what I expect without the hoops I have seen in other languages (search the coding forum for Java help threads; there are only five). For math scripts, I use TI-83 BASIC, because that language was written in math.

What do you mean by 'written in math'?
All computer languages are written in some computer language, and any computer language is ultimately a representation of maths.
Not too many languages are based on a previous mathamatic notation outside of their own algebraic statements (1+2 or 4*5 etc.) I know Lisp was based on Lambda Calculus, which represents everything as a function (even integers).

I want a high-level, capable language in which to write device drivers and operating systems. It's been 30 years since the invention of C, which made practical compromises on its feature-set to suit its own era. Why do we still use such a godawful language in our most fundamental software?!

Dear Lord, why would I write something so boring as a web app?

Common Lisp implementation that runs on bare metal, and allows for in-line assembly for tweaks:
http://common-lisp.net/project/movitz/
Not 100% compliant with the standard, but it's not as popular as it could be if there were more people interested in things like what you've mentioned. needs more developers who are interested in assembly-level programming and high-level programming.
Most Lispers are pragmatists, and write their code on whatever platform has the best support at the terms they like. Alot of the big Common Lisp hackers run OS X just because it's solid underneath and easy to use and comes set up. if they write their code right it'll run the same anywhere, so they don't worry about those things.

If you decide to work on a kernel in it, I'm interested in helping, if not especially capable.

As to why someone would write a web app: Money, ease of access to many users.

[tylerwylie]

Python, because I picked one at random and am still learning it. Do want to branch off into others though soon

[headprogrammingczar]

EDIT: To stay on topic, I prefer Java, because it consistently does what I expect without the hoops I have seen in other languages (search the coding forum for Java help threads; there are only five). For math scripts, I use TI-83 BASIC, because that language was written in math.

What do you mean by 'written in math'?
All computer languages are written in some computer language, and any computer language is ultimately a representation of maths.
Not too many languages are based on a previous mathamatic notation outside of their own algebraic statements (1+2 or 4*5 etc.) I know Lisp was based on Lambda Calculus, which represents everything as a function (even integers).

What I mean is, its syntax is the closest to math-on-paper that I have ever seen. Take matrix math. Multiplying a matrix by its inverse is:

Code: Select all

[[1,2][3,4]]*[[1,2][3,4]]^(-1)

It has similar stuff for functions, plots, series, distributions, differentiation, definite integrals, and more. Arrays are arrays, except they are actually sets, which can be used as arrays, or you can find the mean, standard deviation, median, mode, and every other test statistic you can think of. Lisp is definitely better, but my mind has trouble parsing parentheses, after using other languages.

[xyzzy]

You could do the same in lisp, with a few functions extra to handle it. So a matrix multiplied by it's inverse would be:

Code: Select all

(matmult ((1 2) (3 4)) (matinv ((1 2) (3 4))))

For suitable functions matmult and matinv.

And if you don't like the parens, there's a scheme srfi that implements I-expressions, which allows you to use indentation in the place of parentheses. That could make it into:

Code: Select all

matmult
    (1 2)
    (3 4)
  matinv
    (1 2)
    (3 4)


Presuming I've remembered the fiddly bits right. You can't really get much clearer than that. (For the interested, what's happening behind the scenes is that changes in indentation get replaced by the appropriate parentheses, then the expression is evaluated. For more, read the link above.)

Unsurprisingly, I like scheme.

[MHD]

I absolutely love haskell.

It is by more than a gigaparsec the most concise language I have ever worked in.

Everything just "clicks"

I am working on a generalised interface to the Linear-Feedback-Shift-Register (LFSR) pseudo-random generator family (AKA, Mersenne Twister and friends) and I find that I can make do with a single definition of the entire LFSR operation.
Also, the LFSR operation itself is about 5 lines of code...

Then there's the odd fact that OpenGL/GLUT is fantastic in haskell. This is probably because the IO monad is technically data, you can make your own flow control, and because the modularity of haskell makes it possible to do away with the "gl" part of "glMatrixMode"
Haskell does imperative code better than C. Think about it.

By virtue of being a pure functional language with pattern matching, haskell is also perfect for programming language design. Currently I am working with a derivative of Google GO, trying to apply Ada's generics model and clean out the syntax.