jpr

Sadly, everything he says is true. I wish someone would slaughter Python or Ruby the way yosefk and others have done for C++.

> postscript would be an absolutely terrible choice: the barrier to entry is simply too high.

You say that like it's a bad thing.

Not much information, but everything seems to indicate it would be more of a game than a simulator. I hope that it has as good add-on capabilities as the previous versions.

I'd appreciate it more that it wouldn't answer it at all. Giving stupid answers to stupid questions is even stupider than asking the stupid question in the first place.

To me, it seems that the purpose of a most compilers for statically typed languages is to either generate a lot of type information (*ML, Haskell etc.), or require lot's of redundant typing (the keyboard kind) (Java etc.), only to throw it all away during compilation. This makes no sense at all to me.

Coming from Finland, this was my first reaction too.

In Common Lisp you can embed arbitrary data structures in to your code because the reader can build them at read-time, and it can also evaluate arbitrary code at read time (you can turn this feature off for safety). So "embedding a graph" means something totally different in CL. The CL reader can also basically read both persistent pointers (symbols) and ephemeral pointers (the #N= #N# notation with which you can even read self-recursive structures).

Contrast this to Java, where there are no literal datastructures, no reader, and all your data structures must be explicitly built from constructor up.

I really wish these things would be something that people would be thaught at universities, but thanks to Java-schools, they aren't.

I think the oo-like call chain is nicer when you don't have any arguments and stuff doesn't nest. The difference of static vs. instance methods also makes it slighly more complicated to comprehend. I think overall the simplicity of Lisp-style nesting wins when the expressions get more complicated.

Sounds pretty much like Go, which I personally don't find all that fascinating, in the same sense that I don't find C fascinating.

I really wish that in the near-ish future some group of people, be it a company, research group or just a bunch of hackers would create something that would cross-breed the best ideas of say Lisp, Haskell and Python in a coherent way to create something really fascinating.

By the way, what is the idiomatic way to do this in Python?

    (let ((x 1))
       (defun less () (incf x))
       (defun more () (decf x)))

Not allowing what? Rebinding of variables? That's what IORefs, MVars etc. are for.

Modern VB is certainly good for that. But calling it BASIC is like calling Common Lisp LISP.

Only if the TOS isn't unethical, immoral or lying.

tl;dr, he just wants a language that somehow magically has all the features of C++ while somehow magically not sucking at the same time. Also, regarding the first 2: fuck you too, author.

Uh-oh, if 3/4 of people can't conversate, couldn't it just be that people aren't meant to do that?

Did you even watch the video?

I'm not sure what you mean, since current compilers already warn if you write that code.

A lot of people seem to be horrified that you can cast constness away. Maybe they have more traumatic experiences than I do, but I believe that if something is possible to do (modifiying an object that is declared const), it should be possible in the language as well. That does not mean it should have well specified semantics or that it should be done without proper considerations.

Programming in C++ made me realize how naive C is, in both good and bad.

I have been thinking about user interfaces a lot in the back of my mind. I think that most applications could be made much more usable if the user actually had an idea about what kind of data the application is actually handling, where it's getting it and how it can be manipulated.

What I would like to see is an UI that can represent any kind of data within a consistent framework of GUI-widgets or whatnot. Everything in the UI should be searchable, inspectable,sortable and otherwise manipulable via some real programming language.

Good job on redefining the meaning of equality.

I hope you never misstype your password on OpenBSD.

Learning new stuff is cool. Relearning same old stuff in different clothing because someone decided to do something differently is not cool.

How does that whole "pipe entire objects back and forth" thing work? I mean it seems that there must be some huge machinery to facilitate that kind of thing. For example, if I pipe object from my program to another, how does the other program know what to expect? It must have some sort of type information available, which imposes some pre-planning.

Also, when I pipe an object to another program, can the receiver call methods on it and are the changes visible to the sender?

That looks like a nice solution. I wonder what the question was.

If that were the case, the set of programmers who use C++ should be much smaller than it is currently.

To me, this article describes yet another reason to not even try learning C++.

I would say "outside".

Yeah. I think I would personally go for two fields -- first name and last name -- with a hint that 'if unsure, use lastname' so that the rather common(?) 'sort by lastname' would make at least some sense in most cases, and the requirement that at least one of the names must be non-empty.

Well, as far as I can tell, you are screwed anyway you do it, so you might as well do the simplest thing.

Huh, isn't it obvious? Accept anything as a name.