Herman Venter, programming language enthusiast - All Comments

re: Let’s start again

Robert Stewart — Tue, 10 Jul 2012 19:46:51 GMT

As a former users of one of your previous "exclusive club" languages, I look forward to seeing the new language...

re: How are Scripting Languages different from general Programming Languages?

Gary — Fri, 13 Jan 2012 14:39:39 GMT

a program is compiled, a script isnt?

re: Let’s start again

Herman Venter — Wed, 25 May 2011 17:15:54 GMT

This is a perfectly reasonable reaction. I first enountered it in my student days when the professors debated whether to keep teaching in Fortran or perhaps switch to this new fangled Pascal thing the language enthusiasts were toting. No doubt the team creating Fortran had a lot of people advising them there is no need to make yet another language.

It seems very likely, however, that there will be continued evolution. The JVM and the CLR will stick around for a very long time yet, as will Java and C#. But they will keep evolving in a slow and thoughtful manner. Meanwhile, the enthusiasts will do their thing. Perhaps a new language will come out of it and by 2020 JavaScript will no longer dominate the mindshare of new programmers. Perhaps not. But this blog is about the fun of thinking about that evolution and what comes next.

re: Let’s start again

Rik Hemsley — Mon, 23 May 2011 09:14:59 GMT

I don't understand why it's desirable to make yet another new language.

There are many great languages out there.

Why push only one language as 'the' client-side browser language?

What I really want to see is browsers supporting a JVM or the .NET CLR, so I get a choice of language.

I'd prefer the CLR, of course!

re: Numbers are up

hermanventer — Sun, 19 Apr 2009 23:03:37 GMT

I expect that the numbers we already know and love will continue to be available and used. They are the way they are for good reasons and serve many purposes very well. The question at hand is mainly whether these numbers should have special status, or whether it would be sufficient to treat them as ordinary data types.

As for the arbitrary precision "Rational" numbers that I'm wondering about, those are not an attempt to solve the unsolvable problem of using a finite computer to represent arbitrary numbers from an infinite domain, but a speculation that for casual arithmetic, we may be better off with a representation that does not lose any precision that is expressed in the language source code (by using a fixed number of bits or converting from decimal to binary) and also preserves the expectations we have from high school arithmetic in common cases.

I don't mean to might light of a complex subject of which I am no expert, but I also find it unsatisfying to accept that the current state of the art is "as good as it gets".

re: Numbers are up

Mihailik — Thu, 16 Apr 2009 02:03:54 GMT

That's an arbitrary choice anyway. After all, how would you define a type of Math.Pi with your Rational approach? OK, at least specify the result type of Math.Sqr if you please.

The problem is provable unsolvable, as you should know. There are numbers which cannot be finitely represented, whatever cunning system you choose. To be absolutely precise, most of numbers cannot be finitely represented.

This all means Rational number type you are proposing has no clear preference over existing system.

Common Compiler Infrastructure released on CodePlex

Kirill Osenkov — Wed, 15 Apr 2009 22:31:46 GMT

Great news – Herman Venter from Microsoft Research has released CCI (Common Compiler Infrastructure)

A bit of help compiling your next .NET hosted programming language | Microsoft Share Point

Wed, 15 Apr 2009 09:58:46 GMT

PingBack from http://microsoft-sharepoint.simplynetdev.com/a-bit-of-help-compiling-your-next-net-hosted-programming-language/

infoblog » Numbers are up

infoblog » Numbers are up — Sun, 29 Mar 2009 01:23:16 GMT

PingBack from http://blog.a-foton.ru/index.php/2009/03/29/numbers-are-up/

re: Is there a contract in your future?

Peter Torr - MSFT — Thu, 15 May 2008 23:12:25 GMT

One thing that will be important for security is that contracts not just say "this will be true on exit" but also a guarantee that "...and nothing else will happen." Many security bugs are caused by unforseen side-effects of code, or subtle changes in behaviour made to code over time. Silly example: eval() guarantees that if you pass in a valid expression, it will return the correct result... but it fails to mention that it might also format your hard-drive if you pass in a different kind of source code. This is a highly contrived example, but it highlights how developers (fail to) think about security problems.

Unfortunately it is virtually impossible for the calling code to define a contract stating the totality of what can and cannot happen (or to even understand such a contract defined by the function implementor) since in theory the two pieces of code know nothing about each other and about what side-effects may or may not be acceptable. For example, the naive script developer would need to know that she needs to be worried about hard-drive formatting before she can correctly reason about the contracts / invariants needed for her program (which likely has nothing to do with hard drives at all).

Security systems such as the CLR deal with this specific example (don't let web apps have access to the hard drive) but they rely on a LOT of hard work under-the-covers to enforce the security semantics (web apps *do* access the hard drive, just not directly) and they don't protect against "algorithmic" security problems (those that can't be fixed by gating access to a specific resource).

From another angle, operating systems spend a large amount of time trying to abstract away the details of the underlying hardware, but those very details might be critical to the correct execution of the system (side-channel attacks on guessing AES keys, for example) even though in the vast majority of cases they will not be (hence the desire to have abstractions in the first place).

A more holistic approach to program behaviour, resoure utilisation, etc. is needed to create significantly more secure code, but that sounds like a daunting task!