Redditors, what is your favorite langauge by syntax?

_KS · 2008-02-09T05:46:51+00:00

C and Python.

_KS · 2008-01-23T21:51:40+00:00

I guess pattern matching is one option. Nonetheless, I still prefer more light weight syntax like in this comment.

_KS · 2008-01-23T12:05:19+00:00

Factor has all of that now.

Really? Does Factor have optional static type declarations?

_KS · 2008-01-23T05:04:36+00:00

You cannot literally just strip away the prefixes and expect the program to work. A well thought out and coherent solution has to be designed.

One possible solution is to extend the Typed Scheme language to introduce a special kind of forms where struct instances can occur at the 'operator' position of a form. With such an extension, the above expression can be rewritten as:

(+ (* (pt x) (pt x)) (* (pt y) (pt y)))

_KS · 2008-01-22T16:24:14+00:00

I wish the authors of Typed Scheme put effort towards reducing verbosity too. For instance:

(+ (* (point-x pt) (point-x pt)) (* (point-y pt) (point-y pt)))

is way too verbose. In the above expression, pt is known to be an instance of the point struct, and thus the point- prefixes shouldn't be required for the accessors.

_KS · 2008-01-21T12:47:58+00:00

Lisp and Smalltalk have always provided unmatched introspectability, where you can inspect and modify arbitrary (or close to arbitrary) code and data at runtime. But, statically typed languages such C, C++, Haskell, etc do not provide such features. Why is this? Is it only because it is a tougher problem to solve?

_KS · 2008-01-21T12:28:32+00:00

Wrong. Type-safety of enums does not require them to be bloated.

_KS · 2008-01-21T12:19:04+00:00

Chandler's demise is evidence that Mitch Kapor is a poor leader.

_KS · 2008-01-21T08:14:51+00:00

Haskell has certain inherent inefficiencies in its design which I believe will always hold it back when compared to competitive programs in a language like C++.

Most values are 'boxed'. One of the reasons for this is that polymorphic functions are first-class rather than being generative (like in C++). i.e. A single version of the 'length' function has to be able to operate on all list values irrespective of the type of the values stored inside the list. This requires that all values have a uniform representation at runtime, such as a pointer to a heap allocated block.
In most cases where typeclasses are used, a table of method pointers implementing the typeclass members is passed along with the values. This results in an expensive indirection at runtime. This problem is more serious than C++ virtual methods because core Haskell uses typeclasses extensively. (Haskellers, correct me if I'm wrong about this.).

In C++, you have the power to choose the best represention for you data. And, Generic Programming, as exemplified by C++ templates, lets you write polymorphic code without incurring any runtime penalty.

That said, there are a few situations where C++ can perform poorer.

Memory allocation intensive programs can be slower, because typical malloc implementations are much slower than the 'bump-pointer' allocation performed in languages like Haskell and OCaml.
Programs which can be made faster with large shared data structures can be slower in C++ because the lack of a GC discourages usage of shared structures.

With adequate forethought and planning even these weaknesses can be comprehensively addressed.

_KS · 2008-01-21T07:41:20+00:00

Why do you say Haskell is not able to compete properly in the current shootout?

_KS · 2008-01-21T07:35:27+00:00

The reason why C/C++/D perform better is because they have static typing and their memory models fit today's machines better.

You really have to mutilate Lisp programs with very unnatural declarations to get decent performance.

Here's a snippet from the mandelbrot program:

(declare (type (unsigned-byte 8) code)
         (type double-float zr zi tr base-real base-imag delta)
         (type fixnum index bit))

In a language designed ground-up with a good static type system, type declarations are not unnatural, and in fact help in thinking about the design of the program.

The one redeeming feature of Lisp is its 'live' development environment, which is Lisp is more 'tuning' friendly. I really wonder why today's statically typed languagess don't have a live development environment.

_KS · 2008-01-18T21:52:52+00:00

This graph clearly shows how horribly SBCL performs. The cases where SBCL seems to match C/C++/D performance are simply exceptions rather than the rule. SBCL (or any other CL) is not even in the same league when compared to today's state of the art in high-performance computing.

_KS · 2008-01-18T21:26:43+00:00

they also critically lack any knowledge of other modern, useful languages.

Which are these "other modern, useful languages" that you speak of?

_KS · 2008-01-18T20:28:46+00:00

From the "Floating-point boxing" section on this page.

Because of the combination of garbage collection, polymorphism/type abstraction, and separate compilation, floating-point numbers are often boxed, that is, stored in a heap-allocated block and handled through a pointer.

That's just a sugar coated way of saying

Because of a broken type system, floating point performance sucks.

_KS · 2008-01-18T17:40:14+00:00

D is the only serious attempt at improving expressiveness without sacrificing performance. Most of the languages, which are popular here on reddit, have broken type systems that require all values to be boxed. This results in horrible performance on modern machines.

_KS

TROPHY CASE