You probably mean a very limited number of web app frontend code. That may be true. But I think you underestimate what is being done with software.

With a language that is 200 times slower than C or Java you can't do any data analysis, graphics or image processing, machine learning, algorithmic optimisation, financial software like trading, pricing and risk management, embedded systems, bioinformatics, simulation and a whole lot more.

You're basically excluding yourself from doing anything that mankind couldn't do before. Progress it's called. Most AI tasks require massive computational power. But even just things like pickling a Python object is too onerous for Python itself. I don't think that's good enough.

I'd be happy with just winning that battle.

The horror. The horror.

In the early days, the fact Unix was written in C was quite remarkable. At that time, OSs were written in hand-optimized assembly language.

I see no reason to stay with C-level languages (C was once called high-level) if we can make compilers that translate them into machine code that's faster than hand-optimized assembly.

Smalltalk/80 and the various Lisp machines are sufficient proof whole environments, from kernel to GUI, can be written in higher-than-C-level languages, provided the machine is fast enough. If we can extract speed from compilers and not from expensive silicon, I see no reason not to do it.

In a couple days I will attend to a lecture on porting the Squeak VM to FPGAs and running Smalltalk on silicon. That should be interesting.

There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality JIT to machine code with no primitives.)

The evolution of programming languages will never end, not in our lifetime certainly, and probably not as long as we walk the earth.

You forget to mention a big factor: speed of cultural transmission. Considering what Lisp, Smalltalk, Self and other languages have been able to achieve for high level languages, why are we still dealing with poky high level languages like Ruby and Python? A part of it is cultural expectations. We still expect HLL to be an order of magnitude slower, even though that expectation is decades out of date, technologically. (HLL should only be 70-50% slower now.)

Ruby in particular is basically Smalltalk + Lisp for regular people - it's taken a good chunk of the concepts and packaged it in a way more people are happy to work with.

First time I read about Scheme I was fascinated. Until I played with it a while and put it away and promptly went back to lower level languages (C, Pascal and M68k assembler at the time) because the syntax (or lack of ...) was just too alien for me.

Same with Smalltalk.

Yes, I discarded them over syntax. Speed never entered the equation - I dropped them before I got to evaluate performance.

Ruby is the first language I've worked with that could do justice to a lot of the concepts from Smalltalk and Lisp.

I very much doubt Lisp and Smalltalk has much hope of wider use than they see now - most of the important features are being added to other languages, and the remaining ones are not seen as useful enough by most developers to be worth the painful syntax.

The computational models and the work done on compiling them efficiently will contribute a lot though. Most Ruby implementations in the work and several Javascript implementations are all over PIC's and other concepts take from the Self project, for example.

Do I take issue over other people using other syntaxes? No. Does syntax put any kind of limitation on VM speed? No. Do I even imply that Smalltalk and Lisp are conceptually superior to Ruby? No.

What I am saying is that the current popular HLLs are behind the curve in terms of performance.

I find it funny that adult techies discard Smalltalk over syntax. There's only 5 rules, FFS. Lots of grade school kids have used it like a highly advanced multimedia Logo. That said, the traditional operator precedence of algebras is such a deep part of Engineering, Science, and Mathematics culture, that any language that doesn't add it as a convenience to those groups is probably and understandably doomed to obscurity. (In particular, Forth, Smalltalk, Lisp, Self, and others.)

If only David Simmons had better marketing and community organizing skills. Smallscript might have been where Ruby is today.

I think that's the main problem. There are lots of "Lisps" out there besides Common Lisp (which is what most people think of when they hear "lisp"). I.e. Scheme, newLISP, and Clojure come to mind.

Pick one of those three Lisps and learn it, you'll be wondering why anyone in their right mind would consider writing in any other language, unless it was a lisp. As someone once said, there's a reason people become Lisp zealots; just take a look at it.

Plenty of software is not web-based or a cron job for Linux.

Java, C# are chosen not just because of speed.

You can get vendor support from Sun for their JVM stack. You can (try to) get similar support from Microsoft for .Net stack.

Then also there are personal preferences ::

. Static Typing can be a key part of how people build complex systems in a way they feel comfortable with. When my team codes that way, may bugs are picked up at compile time versus deploy time.

. JVM has really nice remote debugging

. JVM is much closer to run-anywhere than Python

. JVM exits with hs_err files logged

And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer.

If it were true, why would Java programmers use JUnit?

Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.

I disagree that testing blindly is scarcely better than manual QA. If it's automated, the cost of leveraging your tests is small. The cost of adding more tests is not multiplied by iterations. With automation, increased frequency of tests can be used to localize the cause of bugs to particular changes in time.

A lot of the pain of strong typing goes away with type inference - and strong typing means you get much better tool support, e.g. you can see a problem right there highlighted in your editor, you don't need to wait for the unit tests to run on your nightly build!

Maintenance is tangential? Most of the work across all of the fields of programming is probably maintenance.

If you are doing exploratory programming, what does unit testing get you?

It gets you the ability to change your mind and do deep reworkings of very complicated systems with a higher degree of confidence. It's most valuable for maintenance, while duck typing, however.

How can you write the tests before the code if you don't have a spec to work from in the first place?

You end up doing better interface design at a finer granularity than you would have to otherwise. It slows you down, but requires greater discipline in terms of good architecture, so you end up saving time that way. Test first is really just design-up front, but with 3 or 4 orders of magnitude more iterations.

This is best for duck typing languages. Would I unit test in Eiffel, which supports Design By Contract? Doubt it.

you don't need to wait for the unit tests to run on your nightly build!

In the original Extreme Programming, one ran unit tests before checking in any code!

I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too!

In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved.

I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.

I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? Wouldn't you then lose a great deal of the leverage of using a freedom language?

Is this a deliberate troll? Failure of reading comprehension? Where do I ever advocate static types as a replacement for Unit Tests? Why would a Smalltalker ever do that!?

I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release?

There's a big difference between inserting a bunch of tags like <Integer> at the end of the development cycle, probably guided by a coding tool, possibly using Hindley-Milner type inference to automate part of the process, and rewriting. (See Haskell)

Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax? Please give an example that would require something as extensive as a rewrite.

EDIT: To clarify, Strongtalk type annotations are completely optional. Take almost any code, remove the type annotations, and it will run exactly the same. They are also always just the Class Name. In Strongtalk as in Smalltalk, evenything is an Object, so all types are simply Class Names. No complex types at all.

Whoa, what are you talking about? Ironically, I think you're the one failing at reading comprehension. Read the thread. Clearly my "static types as a replacement for unit tests" comment was referring to the post I'd responded to initially. It had nothing to do whatsoever with what you said. I was essentially acknowledging your point, but saying that some people seem to advocate static typing for everything. Calm down bro.

Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax?

Actually, no I didn't, and yes I'm unfamiliar with it ... that's why I asked you for more info.

the rest of what you said

This is all interesting to me. I'm only lightly familiar with Smalltalk and Strongtalk. I was asking for clarification because I really wasn't sure I knew enough about it. Again, no trolling intended ... no need to be defensive.

Read my posts! You're putting someone else's words into my mouth! (Ones which are uninformed and frequently used themselves to troll!) So, there should be an implicit assumption that every thread is diametrically opposed around the issue? And everyone who doesn't follow that assumption and inserts informative neutral concepts are "not paying attention?" I find that intellectually limiting, to put it kindly.

Calm down bro...I was asking for clarification because I really wasn't sure I knew enough about it. Again, no trolling intended ... no need to be defensive.

No, you were putting words into my mouth due to inattentive reading. I'm not being defensive. I'm going on the offensive. Being inattentive and putting words into someone else's mouth and being called on it is not your cue to tell them to mellow. In my book, it's time to demonstrate some intellectual integrity and apologize.

I thank you for your most illuminating reaction!

Still, some of the errors you would catch with static typing you can catch with unit tests. It's not a replacement, but probably better than nothing.

Do you really believe that?

1. It is easier and quicker to develop a correct solution in a higher level language than a lower level one.

2. Expressiveness / abstraction come at the cost of time and space efficiency.

Thus, if time and space efficiency are not a concern, then the higher level language should be preferred.

Not all code written in C is performance-critical. But sometimes it's still the best choice if your code is directly talking to hardware.