Talk:Oz (programming language): Difference between revisions

Content deleted Content added
Cewbot (talk | contribs)
m Maintain {{WPBS}} and vital articles: 1 WikiProject template. Create {{WPBS}}. Keep majority rating "C" in {{WPBS}}. Remove 1 same rating as {{WPBS}} in {{WikiProject Computing}}.
 
(2 intermediate revisions by 2 users not shown)
Line 1:
{{Talk header}}
{{Old AfD multi|page=Oz (programming language)|date=1 September 2013|result='''keep'''}}
{{WikiProject Computing}}banner shell|class=C|
{{WikiProject Computing|importance=mid}}
 
}}
== Article lacking ==
This article lacks source examples and a discussion of how the different paradigms encompassed by Oz "harmoniously blends together". In its current state it is ''factually'' informative but of little actual informative use for programmers or computer linguists. [[User:Mikademus|Mikademus]] 13:00, 9 August 2006 (UTC)
Line 101 ⟶ 102:
 
Fifteen years on, it still assumes that the reader knows the language. What is "browse"? What is special about the examples which demonstrate that it's "allowing higher order functional programming"? It's reasonable to assume that the reader understands concepts like "first class values" (which generally have Wp pages) but not that he's already familiar with the syntax and semantics of the language being described... why would he be reading the article if he were? [[User:MarkMLl|MarkMLl]] ([[User talk:MarkMLl|talk]]) 20:22, 15 July 2021 (UTC)
 
== is Oz always 50x slower than GCC in practice? ==
 
If a problem stated in Oz is solved in 1 hour, but that problem coded in C++ is still not solved after 50 hours, then in practice is that Oz program very slow as stated in this article ?
The conjectured Oz program may have used >50x resources, but if those resources are cheap given the value of the solution, then even that inefficiency might not look like a failing in practice.
This is all so obvious that the "very slow" statement reminds me of the "very large" programs complaint against Smalltalk, when those Large programs were Very flexible in rapid response to mission critical business issues and fostered effective team engineering transparency with small units of code ... in practice and reliably so.
[[Special:Contributions/174.118.226.83|174.118.226.83]] ([[User talk:174.118.226.83|talk]]) 14:07, 10 January 2022 (UTC)