permanent substitute for C

can we ever move on from C?

Yes, anything.

Yes, anything but Lisp.

is Lisp the new Nigger?

or was Ngger the new Lisp...

C and modern hardware have evolved together. Perhaps if we ever jump to a radical new way of making CPUs, we will also jump to a radical new lingua franca.

>>6
Modern hardware have evolved to accomodate the kludges of C.

How about a Lisp with forced type declarations?

>>8
most Common Lisp compilers let you do this for optimization. It's optional though. Why shouldn't it be?

>>8
No.

>>8 ONE WORD: FORCED DECLARATION OF THE TYPES
/NO THANKS

>>8
You mean like Typed Racket?

http://docs.racket-lang.org/ts-guide/

Looks pretty terrible if you ask me. There's quite a bit of new syntax here which looks like it would grossly complicate macros and code generation.

>>12
I'd rather write {code (: x T)} than a cascade of {code declare}s, but it does look bad.
It also lacks many of the things that make statically typed languages appetible. You'd think they're about type safety, and you'd be wrong: they're all about type-driven polymorphism and inference. TR lacks both.
I only use it for the removed list checks and the wonders it does with floating point optimizations.

>>13
Fuck, forgot to compile the Sexpcode.

>>13
U MENA palatable

>>13
It also lacks many of the things that make statically typed languages appetible. You'd think they're about type safety, and you'd be wrong: they're all about type-driven polymorphism and inference. TR lacks both.
God, yes, THIS. Finally someone who understands. Parametric polymorphism and automatic type propagation allow truly concise, literate code in a way that is not possible in a dynamic language.

You should take a look at Clay. A new language in its infancy by a random guy, but it looks promising. It's basically C, but with type parametrization and inference/propagation. One of its killer features is that type parametrization is totally automatic; just leave off the types, and your function is automatically templated on the type of that argument.

There are plenty of downsides though. For one thing, it's even more statement-oriented than most of the C family, which in my opinion really goes against the goal of conciseness. It also has no meta-programming facilities other than type parametrization; there are no macros, no easy way to generate code.

Can we please just combine Lisp and Clay? ;_;

>>16
CLOS, ignorant noob.

>>16
also, you'd be surprised how much you can get with just lambda + switching on symbols: http://letoverlambda.com/index.cl/guest/chap2.html#sec_1

this is essentially what Javascript and Lua are as well.

>>14
No problem, I'll just (compile) your post.

>>17,18
Yes, I am aware that OO is basically a glorified structure of closures, and that JavaScript does this almost literally.

What's your point? It has nothing to do with what we're talking about. This is about parametric polymorphism, i.e. dispatch / overload resolution entirely at compile time.

>>16
Don't get me wrong, I like both dynamic and static types, both have advantages and disadvantages. Dynamic types are more flexible, and you don't have to do S&M with the type system (like trying to type flatten), static types are lovely for the amount of mental masturbation behind them (like trying to type flatten). Multimethods are a good enough replacement for static types in dynamically typed languages, though you'd still miss nice things like polymorphic constants and return types.

Clay. The idea is (almost) good, but the application is bad. I see three major flaws:
- Lack of a system to group overloaded procedures, like ML modules/functors or Haskell's typeclasses. This means that overloads are just left in the wild, and causes template-induced bloat, because the compiler can't do implicit dictionary passing and has to duplicate the code of the procedure (just like in C++). Scala-like implicit parameters would be really helpful here.
- Lack of some kind of subtyping, or my Ord really wants to be a Eq too.
- Operators are fixed, special syntax for magic overloaded procedures.

The site says it has strong support for metaprogramming, but I don't see any example of it.

Can we please just combine Lisp and Clay? ;_;
I don't think you can force types to Lisp without making it look awkward (see TR), and homoiconicity, types and metaprogramming don't play too well together.
If you want a concise, statically typed language, surrender to Haskell.

>>21
I don't think you can force types to Lisp without making it look awkward (see TR), and homoiconicity, types and metaprogramming don't play too well together.

I refuse to believe that this is true. Just because it doesn't exist, and everyone who has ever tried to do it has failed, doesn't mean it can't be done. It can! It must! I WANT TO BELIEVE

>>22
TR is probably going to make some steps forward on typed macros, but it probably will not make typed Lisp less awkward. Haskellers aren't going to do any research on that, they're too busy believing that lazyness removes the need of macros.
So, try writing your own.

I see I'm not alone in wanting a C with a better type system.

>>21
polymorphic constants
wat

Also, the advantages to compile-time dispatch that I can see involve lazy evaluation as well. For an eager language that doesn't need every singe instruction to be uber optimized, I don't see why something like CLOS is more than sufficient to superior to a static type system (as far as dispatch is concerned.)

>>25
wat
Prelude> :t maxBound
maxBound :: Bounded a => a
Prelude> maxBound :: Int
2147483647
These are nice to have, sometimes. Polymorphic return types too.
I don't see why something like CLOS is more than sufficient to superior to a static type system (as far as dispatch is concerned.)
I don't like all the mutation that happens under the hood in CLOS, and all the locking that's required to make it thread-safe. Is there some multimethods implementation (just multimethods) that doesn't require locking and is thread-safe?

>>7
Exactly what kludges are you referring to?

>>27
Lack of car/cdr primitives.

>>28
They are pretty shitty.

>>27
Lack of support for tagged pointers, a better memory model, hardware garbage collection, etc.

LISP

>>1
a wall mounted dildo

>>30-31
suge http://www.banknotes.com/BW6.JPG