I'd like to have a language which
1. Is strongly typed;
2. Can be both interpreted and compiled (no virtual machines);
3. Has a good library;
4. Well integrates linux;
5. Object oriented;
6. Not complex as C++.
Racket is strongly typed, can be interpreted and there's a compiler for it, comes with batteries included ranging from web application servers to OpenGL, works great under GNU/Linux (the IDE, the compiler, and the compiled code; everything), is object oriented (please define object oriented though; it supports classes and every value is an object but not every value is an instance), and it's far less complex and far nicer than C++.
>>10
1. Closures are not non-compilable.
2. OP doesn't know what he's talking about.
3. Ignore that part.
4. See how mzc works, that's ideal.
BTW, naïve C code dealing with minimally complex data structures and compiled with GCC is actually slower than equally as naïve equivalent Scheme code compiled with mzc. OMG OPTIMIZED is brokan!
>>15 BTW, naïve C code dealing with minimally complex data structures and compiled with GCC is actually slower than equally as naïve equivalent Scheme code compiled with mzc. OMG OPTIMIZED is brokan!
I call bullshit on that and it shall remain bullshit until you supply two equivalent programs in both C and Scheme for which the mzc-compiled binary will outperform the -OZOMG GCC-compiled binary.
>>16
Go ahead, implement simple-as-possible linked lists in C (struct {payload; *next;}), then implement something simple like the Sieve of Eratosthenes, do the same with cudders.
I'll look for the stupid shit I did a couple of years ago; I was trying to determine for myself how much slower would mzc be and I came to a pleasant surprise, probably due to functional programming (conses, immutability, etc.) optimizations.
Why is strong typing a requirement? Do you really like specifying types for everything?
Better questions would be: typed vs untyped, statically typed vs dynamically typed, implicit/explicit typing, auto-conversion vs explicit coercion. I'm not a fan of strong typing, simply because strong typing only implies that you have to specify the types manually. Let's review some modern high-level languages:
- Common Lisp and Scheme: dynamically typed, which basically means in its context that variable names don't hold types, but values themselves are typed.
- Haskell and ML: statically typed, and the types are inferred from what you do with your variables. Varible names are thus typed.
Neither Haskell, ML, Common Lisp or Scheme are strongly typed, because in one case, the types can be inferred at compile-time, while in the other case, the types can be checked at run-time (they can also be checked at compile-time in some implementations). One major implementation difference is that CL/Scheme usually has to use tag bits or some way of specifying the type of a given data, as well as include the needed typechecks where appropriate, while the other one knows what the type is, and thus can just use raw data without tags (this does lead to some programming restrictions). C, on the other hand, is statically typed, but also strongly typed, so you have to specify types for everything, and you may sometimes even do this incorrectly (errors would be bought by the compiler in Haskell and ML, while in CL/Scheme, very detailed and sometimes even recoverable errors will be possible at either compile-time or run-time), which can lead to the usual buffer overflows, integer overflows and other kinds of errors - it also makes it a pain to write generic or polymorphic code, unlike the other languages. 2. Can be both interpreted and compiled (no virtual machines);
This is an implementation issue. Any language can usually be both, unless it has some feature which only makes it suitable for one or the other. Most in-use languages tend to be compiled or at least JITted for performance reasons(C, C#, Java, Common Lisp, Scheme, Haskell, ML), while some are at least compiled to bytecode (Python, PHP(yes, even that), Java) for JIT or interpretation. It's also common for Lisps to have interpreters written for them due to the sheer easyness of writing them, however most implementations are compiled by default. 3. Has a good library;
Most in-use languages have lots of code written for them. Do you mean large standard libraries? Common Lisp, Python, C#, Java, Ruby have reasonably sized standard libraries and a LOT of user-provided libraries. Scheme is reasonably tiny, but with R6RS and all those SRFI's, I could say it also classifies as having decent libraries (portability is another story altogheter). 4. Well integrates linux;
I can't think of many languages which suck on Linux. Maybe Microsoft Visual Basic series. Even .NET is well-supported with Mono. 5. Object oriented;
This is a stupid request, because object orientation is buzzword and its meaning got so diluted over the ages that just about anything can qualify as object-oriented. If you want some truly amazing OO, I'd recommend you check Common Lisp's CLOS (and its MOP) - it's most certainly the most flexible OO system I've ever seen, and if that's not enough, you can use the MOP (read AMOP) to practically define any kind of OO system you can imagine in plain CLOS. If you want something more classical, you can check out Smalltalk. And if you want your buzzword definition of OOP (single-inheritance), go for Java or C#. 6. Not complex as C++.
Few languages are as messy as C++. One large problem with C++ is how syntax and semantics are coupled, making a huge mess. Do you want something very simple or do you want something industrial-strength? For simple, go with Scheme (R5RS). Otherwise, Common Lisp, or even Python would work. CL seems to fit with everything, except your first requirement (which is specifying types), however if you really want to annotate types, it does let you do so (for performance/optimization reasons), however unlike C, you don't really have to do it, except when you want to give hints to the compiler.
>>24
They are modern in the sense that some current high-level languages are actually going backwards with what features they offer. I try to be optimistic and think we won't go all the way back to COBOL and BASIC, but you never know what will happen.
Name:
Anonymous2010-11-04 2:39
>>23
Productivity decreases propotionally to code base size with dynamically typed languages. In large projects I honestly being strongly typed is a good thing.
>>26
Strongly typed only means that you MUST specify types.
A dynamically typed language can let you specify types just fine, and in most cases, you can easily find out what types the arguments to your functions must be (in statically typed languages you just look at the function signature, in dynamically typed ones: documentation, conventions and the language's own introspective features usually let you find them out. I can't say I had trouble finding out what the arguments are meant to be in either language). Strongly typed != dynamically typed or statically typed.
It can also be argued that code base sizes can increase in strongly typed languages.
Name:
Anonymous2010-11-04 3:38
A codebase with a weakly-typed language can make people turn to Hungarian Notation in order to use it reasonably. A codebase with a strongly-typed language will require more type declarations, casts, or function calls. Personally, I prefer this as it promotes type safety.
>>23 strong typing only implies that you have to specify the types manually
I'd just like to point out, in case it isn't already apparent, that the differences with dynamic/static typing and with strong/weak typing have very little in commmon.
Object Pascal
-Strong typed
-Only compiled, but came from an interpreter background(UCSD Pascal)
-Has a nice large library, and units for most used APIs
-Integrates well in an UNIX environment
-Object Oriented with all the bells and whistles
-Way less complex than C++
FreePascal 4 lyfe!
Name:
Anonymous2010-11-05 11:44
>>14
Get back to school. Learn the difference between a compiler and the interpreter, HIBT?
>>41
I remember flamewars from long ago when I with kids argued about "C vs Pascal". I always liked to run pascal code through p2c and measure its time. Then I laughed at pascalfags because code that came through translator runs faster than original. Pascal compilers were so shitty those days.
>>43
I know FPC can't do all the microoptimization that popular C compilers can do, but it's okay. Maybe it'll get a proper instruction scheduler and cache optimizer in the coming year
At least it only takes a few seconds to build the compiler...