Timeline for Why does Java have `void` methods?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 27, 2017 at 14:09 | comment | added | David |
@Luaan I agree that the restriction is limiting. But introducing a type (void) that represents the absence of a type has always struck me as at least equally bizarre. I never did anything with Turbo Pascal, but IIRC Ada allowed arguments to either functions or procedures to be in (read-only), out (write-only), or in out (read/write) ... which seemed to me an eminently sensible compromise/solution.
|
|
| Apr 27, 2017 at 10:10 | comment | added | user207421 | @DamianNikodem The problem with that particular limiting theory is that exceptions are a form of flow control. | |
| Apr 27, 2017 at 9:26 | comment | added | Mike Nakis | @Holger sure StringBuffer had it, because it was thought as the most practical way of working with StringBuffer. However, only StringBuffer had it. It was not thought of as a "style", and it did not have a name. ("Fluent".) Even the builder pattern had not been named back then, and that's why the original StringBuffer was called StringBuffer and not StringBuilder. | |
| Apr 27, 2017 at 9:00 | comment | added | Holger |
I’m objecting the statement that “the fluent style of invocations is a recent development”. That style was known when Java was invented, e.g. StringBuffer exists since the very first version. But that doesn’t imply that this style was deemed to be useful for every class and method. In fact, that assumption would be controversial even today.
|
|
| Apr 26, 2017 at 19:51 | comment | added | Damian Nikodem | seems like people failed to mention that you shouldn't be doing flow control via exceptions anyway. Exceptions are precisely that, for 'exceptional' circumstances. In particular states where you cannot easily recover from. The performance of unrolling the entire stack sucks. | |
| Apr 26, 2017 at 13:47 | comment | added | Luaan | @MikeNakis Pascal was designed according to what structured programming advocates then expected to be a good way of writing large programs. This included the separation of procedures ("subroutines that cause side-effects") and functions ("subroutines that do not cause side-effects"). Procedures were supposed to return values through their arguments, if needed. The practical experience that followed made it clear that while there's many benefits to this kind of thinking, it's also unenforceable and limiting, and there's benefits to opting out of the rigidity (Turbo Pascal was a lot better). | |
| Apr 26, 2017 at 0:45 | comment | added | user207421 |
The real original reason was that by default C functions returned int, so a keyword was added subsequent to K&R to indicate 'no return type'.
|
|
| Apr 25, 2017 at 19:14 | comment | added | supercat |
@8bittree: LIkewise if outside code is going to call functionWrittenInC(), the compiler will need to know whether it should generate a subroutine that can be invoked via procedure call, or one that can be invoked via function call.
|
|
| Apr 25, 2017 at 19:13 | comment | added | supercat | @8bittree: On platforms where procedures and functions are called the same way, a compiler could treat "void x();" as equivalent to "int x();". Such a substitution would also work, even on platforms that use different calling conventions for procedures and functions, if it were applied consistently throughout C programs which never interact with outside code. If a C programs needs to call an outside subroutines on a platform which handles functions and procedures differently, however, the compiler needs to know which subroutines are procedures and which ones are functions. | |
| Apr 25, 2017 at 19:04 | comment | added | 8bittree |
@supercat I'm not sure I understand your point. Are you saying C does have a special syntax for distinguishing between functions and procedures? If so, please enlighten me. I'm pretty sure it can't just be void foo(); because the construct resulting from that has to also be compatible with platforms that don't have special handling for procedures.
|
|
| Apr 25, 2017 at 18:30 | comment | added | supercat | @8bittree: Code written in C is often called upon to call or be called by functions written in other languages, some of which distinguish between procedures and functions. Further, some platforms handle procedures and function calls differently. While the exact details of how outside code is called will vary among implementations, enough systems need a way to distinguish procedures and functions that it's useful to have a standard notation to distinguish them. | |
| Apr 25, 2017 at 18:22 | comment | added | 8bittree |
@MikeNakis I'm not sure why such a decision must have been made. Seems like the designers of C and Java could have simply never even considered distinguishing between them (though the Java folks were probably aware of Pascal). Regarding Wirth, his earlier language Algol W had a tenuous distinction. Both functions and procedures were called procedures, with those that didn't return anything simply lacking a type name before the PROCEDURE keyword.
|
|
| Apr 25, 2017 at 16:48 | comment | added | Mike Nakis | Okay, this is hair-splitting. Java syntax is derived from C syntax. C syntax is derived from other languages. Somewhere along the line, there was someone who said "instead of procedures and functions, let's make everything a function". And obviously, that idea never occurred to Wirth. Does anyone disagree? | |
| Apr 25, 2017 at 16:15 | comment | added | 8bittree | @MikeNakis The claim that Pascal influenced C in such a way is highly dubious without providing evidence, given that C began as a series of modifications to B, which had no syntactic distinction between procedures and functions. | |
| Apr 25, 2017 at 15:15 | comment | added | Thorbjørn Ravn Andersen | It is not obvious. C was developed at roughly the same time as pascal by people who most likely did not even know it existed. Please do not state assumptions as facts. | |
| Apr 25, 2017 at 12:41 | comment | added | Mike Nakis | @ThorbjørnRavnAndersen oh, I see, I misunderstood. So, you want a source for my claim about C, not about Java. Okay, I sorry, I have no source for that. But I think it is rather obvious. (I used to program in Pascal in 1987, when I switched to C. My goodness, that's 30 years ago.) | |
| Apr 25, 2017 at 8:32 | comment | added | Marco van de Voort | They were stingy with keywords. The current solution complicates the language since it is quite hard to determine a function start, specially giving any sane errrormessages if the code is not 100% correct. | |
| Apr 25, 2017 at 8:16 | comment | added | Thorbjørn Ravn Andersen | @MikeNakis If that is the statement you want to make, you may want to consider rephrasing. | |
| Apr 25, 2017 at 7:58 | comment | added | Mike Nakis | @ThorbjørnRavnAndersen are you really, actually, asking me to provide a source for the claim that java's syntax is derived from C syntax? | |
| Apr 25, 2017 at 6:43 | comment | added | Thorbjørn Ravn Andersen | Please provide a source for "The original reason...". To my knowledge the real reason is because C was designed to be portable assembler. | |
| Apr 24, 2017 at 19:07 | history | answered | Mike Nakis | CC BY-SA 3.0 |