3,379 reputation
917
bio website contexo.de
location Germany
age 54
visits member for 4 years, 1 month
seen 7 hours ago

I am interested in functional programming and the java platform.

I wrote and published a programming language named "Frege" (after the great german logician) that brings together both worlds.

The language is in many respects like haskell (syntax, type system, lazy semantics) but allows to use java methods as functions.

For more information see https://github.com/Frege/frege


Apr
8
comment When there's no TCO, when to worry about blowing the stack?
@supercat I think I see what you mean, but just because standard JVMs up to this day let stack space be a scarce resource simply does not imply that future JVMs should do the same. After all, this is not part of the JVM spec. It is possible (theoretically, at least) that a JVM works like the Haskell RTS in that it allocates stack as it is needed up to the point where the entire available memory is used for stack space (and not just a small, fixed area). Once programmers learn this and rely on this, we would have the same situation: you can't run those progs on earlier JVMs easily.
Apr
8
comment When there's no TCO, when to worry about blowing the stack?
@supercat I can't really see a difference here. In both cases the assumption is that some resource is abundant enough to satisfy the needs of the program and those needs depend on the input and have no upper limit.
Apr
7
comment When there's no TCO, when to worry about blowing the stack?
@supercat You are right in principle, but the truth is: in practice we're doing just that all the time! For example, a simple word counting program just adds its stuff to a hash map, as if there were no memory limits. This is justified by the idea that the user can just specify a big enough -Xmx value. And OTOH, in many cases you can't help it without assuming another "unlimited" resource. For example one can keep track of the words in a data base with "unlimited" tablespace, instead of an in-limited-heap-memory hash map.
Apr
7
comment When there's no TCO, when to worry about blowing the stack?
@supercat At some point there needs to be progress, and we need to let go of falsely understood backwards compatibility. Your second example is clearly an instance of this "backwards" fallacy. For, consider the following and tell me, please, which state of affairs is to be preferred: 1) We have 2 JVMs and both can run the code with a problem size of 213. 2) We have 2 JVMs and one of them can run the code with a problem size of 213, while the other can run problem size 1,000,000 or even unlimited.
Apr
7
comment When there's no TCO, when to worry about blowing the stack?
@supercat I fully agree with that, and suggested to use goto foo(args); for this (like in perl). However, a language change is even more problematic than a semantic-preserving JVM change, that's why I don't hope that this ever comes true.
Apr
7
comment When there's no TCO, when to worry about blowing the stack?
@supercat True. And for such cases there should be some switch to turn off TCO, as a debugging help. But such cases are simply no excuse to make an important programming technique virtually impossible, especially when such techniques may help make programs that are arguably less error prone in the first place.
Mar
21
awarded  Yearling
Feb
21
comment Why languages that compile to C/C++ generate unreadable, cryptic code?
Well, ((lambda (x) (+ 1 x)) 17) has a C++ equivalent. Its 18, I guess, or at least 1+17.
Dec
7
comment Which are the cases when 'uint' and 'short' datatypes are a better fit than the standard int(32)?
@JackAidley Obviously much more, in the given context. It goes without saying that one must used unsigned only in contexts where negative numbers make no sense.
Dec
7
comment Which are the cases when 'uint' and 'short' datatypes are a better fit than the standard int(32)?
@JackAidley Exactly. For example, the meaning of 5-6 is a number that, when incremented, yields 0. (We don't conflate "meaning" and "printed representation", do we.)
Dec
6
comment Which are the cases when 'uint' and 'short' datatypes are a better fit than the standard int(32)?
@JackAidley I am quite sure what you say makes no sense, as 5-6 yields the same bit pattern, no matter if its unsigned or not.
Oct
27
comment Long Filename Extensions: Why Not
@Zack Please tell me what exactly in the sentence "There is no such thing as a file extension." you didn't understand? By the way, it should be "file name extension". But even then, in more recent operating systems, like UNIX, it is at best a convention that a file named file.c contains C source, etc. There is no place in the OS where a filename is interpreted.
Sep
27
answered Why do most programming languages have special keyword or syntax for declaring functions?
Apr
15
comment What's the point of adding Unicode identifier support to various language implementations?
Yes, but then, only a few characters look alike and then it is, as so often, a matter of style, coding guidelines and quaity assurance that'd have to make sure you don't use 3 different characters that look like A in one place. OTOH, being a freedom-lover I abhor forbidding something just because one is not sure it could possibly be abused by someone.
Apr
2
comment Zero behavior objects in OOP - my design dilemma
You can even enhance your data objects by making them immutable.
Mar
21
awarded  Yearling
Mar
12
comment Are null references really a bad thing?
null per se isn't bad. A type system that makes no difference between type T and type T+null is bad.
Mar
3
comment Is pattern-matching against types idiomatic or poor design?
How much sense does it make to view a functional language from an OOP perspective? Anyway, the real power of pattern matching comes with nested patterns. Just checking the outermost constructor is possible, but by no means the whole story.
Mar
2
comment What negative consequences can arise from this language design rule?
@yannbane And yet, you compare it with Scala ...
Mar
2
answered What negative consequences can arise from this language design rule?