text:
Talk:Oberon (programming language)

Problems with the current aricle -- long list
I don't have the information to correct this, but

"It also offers an interesting feature which is only recently becoming available in more prominent development systems: exportability of procedures. Imagine that for some program you create a PNG viewer procedure and that you export it: any program on the system will be able to view PNG files merely by calling the viewer! That's true reusability."

is bogus. Code libraries predate Fortran, and shared libraries date back to or before MTS and the late 1960s. CORBA and things like it do this too. I'm sure there's something mildly unique, but I don't know exactly what it is.

 * The original remark must have related to Oberon as an operating system, not to Oberon as a programming language on a foreign OS. In the former case, the function is just loaded into memory once and it could have been used in another program, but also from the command line. AFAIK this was and still is unique. Jan272 (talk) 06:12, 4 August 2011 (UTC) Jan Verhoeven

Likewise,

"The code will be both smaller than that in nearly all other programming languages..."

leaves me sceptical; it sounds like ad copy instead of an accurate statement. Oberon is in the same family as Modula-3, Ada, Pascal, and Java, and more distantly C, so it's not going to produce a huge difference in code size. Perl, Mathematica and APL will blow away any of the above languages in the right problem domain.

"...(mistakes will be less easily lost in a forest of detail)"

Which doesn't follow from the statement it's parenthetical to. Languages that add the detail of a variable definition for every variable save people from many mistakes that were made in Fortran. APL and Perl are both known for small code, and both are known for being hard to read.

"less opaque (fewer language 'features' mean less chance of confusing/misusing them)"

Love the scare quotes around features. How does removing enumerations and forcing people to use integer constants make things less opaque? In general, you have language features because otherwise you have to write a lot of code to emulate them, or because it's more efficent to have the compiler handle it. I had a professor who would honestly argue that programmers should just use a Fortran with extra features added until everyone was happy. Whether or not Wirth's minimalist strategy is good is still being debated, but the average programmer uses a programming language more complex than Oberon, and frequently much more complex than Oberon (C++, Perl, Common Lisp, Fortran 95).

"less subject to error problems from data typing problems"

C programmers might point out that strict data typing like Oberon has is a pain and can add to a lot of type changing, from integer to float, for example, and even worse if you want to start bitwiddling character input. An Ada programmer, like me, would point out that in exchange for that pain, you catch a lot of errors; but Oberon doesn't catch nearly as many errors as it can, and is less portable than it should be, because it doesn't include enumerations and ranges that catch errors and avoid depending on an implementation specific integer type.

 * That is more since Ada is more like Modula-2 (Oberon's predecessor) so only the successor to Ada should be compared to Oberon. Jan272 (talk) 06:12, 4 August 2011 (UTC) Jan Verhoeven

This presents Oberon as the perfect language, and doesn't include any concept that it's not, that the design principles may have tradeoffs. This is not unique: Ada programming language doesn't include much discussion about the tradeoffs either, but mentions the features as facts, instead of saying how much better it is than "almost every other language". (comment by user:Prosfilaes, May 2004)

Sure it's enthusiastic. But worrying about POV is not needed.
The article is enthusiastic. There is evidence that simpler languages have greater reliability. The above comments are all true. Calling an enthusiastic article NPOV seems overreacting. The article could be more encyclopedic by incorporating the comparisons noted above into the article. Kd4ttc 19:57, 2 Jun 2004 (UTC)

 * If in the article on Christanity that "Christians were better people than non-Christians", that would slapped down instantly as NPOV. Writing that "Oberon programs are also less likely to be buggy" is no less NPOV, even if it brings up less emotional responses.

 * I've read about studies to prove that Ada is less buggy than C and C++, but I'm not going to add "Ada programs are also less likely to be buggy" to the Ada programming language page. If I was interested in doing so, I'd have to make it clear the details of the studys, which might give me the right to say that, in many cases, it appears that Ada can have a significantly lower defect rate than C and C++. If studies were made comparing Oberon and other languages, they need to be cited, and then you can say that in the instances of the studies Oberon performed better than the other languages studied.

 * I can't incorporate my corrections into the article, because I don't even know what it's talking about frequently. --Prosfilaes 08:31, 3 Jun 2004 (UTC)

 * Religion and politics get the strongest response so discussions on Mac vs Windows sure get exciting! (Politically incorrect comments on (delete groups) deleted) Wikins seem to be very tolerant.  I think the comment on studies regarding correctness of programs would be very useful in Ada.  The article on Eiffel could benefit there as well, with the interesting observation that commercial success seems inversely related to how clean the programs are, and that commercial success measures only sales of compilers, not utility of languages.  The studies that discussed what goes into creating a reliable language seem to have been lost on a whole generation of programmers.  Lucky grad students in the future, who can rediscover all those studies.  Me: I'm just an old fart medical doctor.  Not up to date on the studies we've discussed obliquely.  I'd like to see the Algol families come back.  I get ill just looking at C code.  At least I'm in good company with Dijkstra feeling the same way.  Once a port of something like Pascal, Oberon, or Modula port to Mac OS and is tightly integrated in the IDE I'll get entusiasm for programming again.  Till then PHP, mySQL, and Apache will have to do.  Kd4ttc 01:36, 4 Jun 2004 (UTC)

Libraries versus features
"It has likewise been argued, failure to include a feature may force the programmer to reimplement the feature in his code, causing many people to code the same algorithms, frequently with bugs or inefficently; however, this ignores the concept of libraries. Java is an example of a simple-enough language surrounded by an enormously rich class library."

First place, it's beside the point; Oberon does not have the rich class library. Second place, it's overstating your point; libraries have different strengths than features. There's no enumeration library that's going to do the compile-time checking and clarity and succinty of built-in enumerations. You can't provide templates in a library, either, and emulated templates aren't as type-safe as the real thing. Likewise, libraries don't give compilers as much information as features do; compilers will frequently give awful error messages with the STL because they're seeing the inside of the template rather than the feature.

Also, are you still a simple language if you have a Java-sized standard library? Implementations still have a long row to how, and it's not like it's any easier or less required to learn about a feature if it's stuck away in a library. --Prosfilaes 12:19, 27 Jun 2004 (UTC)

Smaller=Faster -- not necessarily
I'm posting to the talk page so maybe we can discuss a consensus, instead of back and forth changes.

"Oberon code is typically smaller, and so faster, than equivalent code in many other languages."

Is bullshit. It is absurd to say that Oberon code is typically smaller if you don't specify languages and projects. Likewise, smaller doesn't mean faster. In Code Complete, Steve McConnell shows several functions in C to calculate the integer log base 2 of an integer; the fastest function is the longest.

Or let's look at Hello, World.

10 print "Hello, world"

echo Hello, world

int main (void) { printf ("Hello, world\n"); }
 * 1) include

MODULE HelloWorld; IMPORT Out; BEGIN Out.String("Hello World!"); Out.Ln; END HelloWorld;

Gee, Oberon produces the most code. Do you really think that means that the code will be slowest?

 * I suspect the thought here was object code (or machine code depending on the compiler) as opposed to source text. The Wirthian languages do tend to use actual words instead of one character symbols (or an implicit invocation) for such things as variable typing and such. Thus I suspect the strongly felt comment immediately above is skew to the intent of the article text. ww 20:27, 5 Oct 2004 (UTC)

 * How much object code is produced is completely compiler-dependent. Also, I don't read that and think "object code". I think source code. In any case, before it is put back in in any form, I'd like to see some evidence that it's correct. Even smaller object code doesn't always imply faster code.--Prosfilaes 04:33, 6 Oct 2004 (UTC)

Slim Binaries
Should slim binaries (roughly: dictionary encoded abstract syntax tree of code) get mentioned in the article? See for a little further info on slim binaries. Zarutian 01:06, 22 june 2005 (UTC)
 * Bad link there. The argument seems to be something along these, not so explicit, lines. Snmall binaries have, all other things being equal, have fewer interdependencies and so lower complication and so fewer opportunities for bugs. Well, not intended ones anyway. Which is the general Wirthian point. True, it's possible to have slim binaries which have pathologically interconnected everything, but that's the situation several sigmas out, the unlikely case. After all, not even close to all C programs qualify for the Obfuscated contest.

 * It's a fair comment to make in WP, though hard to quite explain clearly. With all the refs and such WP tries to insist on. It's a craftsmanlike point, and equally hard to understand. In Pirsig's terms, it's a kind of 'quality'. That took a writer of Pirsig's quality to describe, I don't have such hopes of my own prose... ww 16:55, 14 July 2006 (UTC)

Proposal to Merge
I've proposed that the 'Oberon-2 article should be merged into this one. My reasons are --

 * Oberon-1 was never really much used, and needs only to be mentioned as a historical curiosity
 * Oberon-2 is usually called just "Oberon"
 * similarly, several articles that ought to link to Oberon-2 are actually linked to this one
 * most of the available documentation and implementations are for Oberon-2
 * the features that keep Oberon alive only really began with Oberon-2

If you look at the Oberon-2 article, you'll see it's quite short, because once you've discussed Oberon-1, there's not much more to say about it. So, without any negative feelings towards Oberon-1 or -2, I think these two articles should merge; and the Oberon-1 article is larger and better linked into Wikipedia.

What do you guys think?

OrangUtanUK 13:23, 10 August 2006 (UTC)

Makes sense to me. RainbowCrane 15:25, 10 August 2006 (UTC)

Good suggestion - assuming that it is set up so that anybody looking for information on 'Oberon-2' ends up directly in the right place in Wikipedia. Chris Burrows 23:58, 10 August 2006 (UTC)

Requested move
Oberon programming language → Oberon (programming language) – Conformance with WP naming conventions atanamir

See: Wikipedia talk:WikiProject Programming languages/Renaming poll

Oberon-1 → Oberon (programming language) The first version of Oberon is never referred to as 'Oberon-1', just as 'Oberon' (similarly to Modula and Modula-2). Oberon already exists as a WP entry so Oberon (programming language) is the next best option. This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system Chris Burrows (talk) 02:19, 26 August 2008 (UTC)

That's the first time I've ever seen "Oberon-1", and it should go away. Oberon (pl), Oberon-2 (pl), and Oberon (os) should be the names, IMHO, with all three linked directly from the Oberon disabiguity page. htom (talk) 04:16, 28 August 2008 (UTC)

I've been unable to move "Oberon-1" to "Oberon (programming language)" as "Oberon (programming language)" already exists as a redirect page. Chris Burrows (talk) 06:14, 28 August 2008 (UTC)

claim that Oberon is not object oriented
A recent edit by Taw included an edit summary noting the article said oberon was not object oriented. As this can be achieved in various ways, including that used by Wirth et al in the design of Oberon, I suggest that this edit is confused as to the underlying facts. And in any case, the article also says plainly the O is object oriented, just not in the C++, Java, or Smalltalk fashion. Comments? ww 05:22, 20 October 2006 (UTC)

 * I would say that while Oberon supports the practice of OOP, it also supports Imperative programming. It's a component-orientated language, which gives a lot more expressive freedom to the programmer. If I may go all poetical for a moment, the Copernican revolution in programming was the sudden awareness that algorithms should revolve around data and not data around algorithms - an allusion to the discovery that the earth revolves around the sun. But as modern thinkers we should be aware that in fact the sun and the earth revolve around their common centre of gravity, which turns out to be outside the surface of the sun. Likewise, you can't write a decent large software system without understanding BOTH the data and the algorithms. This is an archetypical Niklaus Wirth view - refer to his ancient book "Algorithms + Data Structures = Programs" (Wirth, 1975, ISBN 0-13-022418-9). Let us be glad that Oberon is not ONLY an OOP. OrangUtanUK 19:02, 20 October 2006 (UTC)

 * Oberon-1 wasn't even the slightiest bit object-oriented. In Oberon-2 there's no message passing, not everything is an object (in particular classes are not objects), polymorphism is limited to class hierarchies, and there's no object-based encapsulation. What it really supports is abstract data types and component-oriented programming (it is pretty much irrelevant whether it's "better" than oop, it's just not oop). It supports a little OOP, but to call it is too much to call it an "object-oriented programming language". Taw 17:51, 31 October 2006 (UTC)

 * I disagree - certainly as far as Oberon-2 is concerned. According to Hanspeter Mössenböck, the driving force behind Oberon-2, "Type-bound procedures together with type extension make Oberon-2 a true object-oriented language with dynamically-bound messages and strong type checking at compile time." Ref: http://www.statlab.uni-heidelberg.de/projects/oberon/kurs/www/Oberon2.OOP.html I recommend that you argue the case with him if you disagree: his contact details are http://www.ssw.uni-linz.ac.at/General/Staff/HM/. In the meantime, please rectify the changes that you made and discuss before making such changes in future. Chris Burrows 23:47, 1 November 2006 (UTC)

Merged Oberon-2 article in
I merged the Oberon-2 article in, following what looks like consensus and passive acceptance. Please feel free to vituperate me ... ! OrangUtanUK 18:49, 20 October 2006 (UTC)

I think they shouldn't have been merged. The article started with "Oberon is a reflective programming language" (reflection was added in Oberon-2), and then started to mix them randomly. Like here - "The design continued the Wirth tradition/strategy of attempting to simplify without loss of power. Oberon may be thought of as a Modula-2 with full object oriented class/object capabilities". OOP wasn't a design goal of course - it happened (to the extend it even happened, Oberon-2 was more component-oriented than object-oriented) many years later.

Maybe an article about both that cleanly separates them would be possible, but it's better to have two articles, than one that mixed things up so much. Taw 18:01, 31 October 2006 (UTC)

 * Taw: Please change the name of this page and all Oberon-1 references from Oberon-1 back to Oberon again (I would do it if I knew how). Oberon-1 did not, and does not exist. Chris Burrows 00:08, 1 November 2006 (UTC)
 * I concur with this request. There is an Oberon Report (for what is here referred to as Oberon-1), but not an Oberon-1 Report. The article is thus in error as to the nomenclature of its subject. An awkward position, that, for a WP article. ww 00:16, 1 November 2006 (UTC)
 * I have now logged a move request with the administrators for Oberon-1 to be chnaged to Oberon programming language. There are already redirects so I was unable to do it myself.Chris Burrows 12:32, 1 November 2006 (UTC)

things HAVE GOTTEN OUT OF HAND!
Noticing the problem (as above) as between Oberon-1 and Oberon-2 and all the merging and renaming and all, user:Mets501 attempted to help us with our confusion. There is now a disambiguation page for Oberon, pointing to the two articles. WP can endure a lot, but surplusage in disambiguation pages is too much.

We must delete the disambiguation page, rename the Oberon-1 article to Oberon and, if the merging is complete, delete the Oberon-2 article.

Merger folks, where do we stand on the merge...?

Ok, folks, let's get going... And, ...let's be careful out there. ww 03:26, 4 November 2006 (UTC)

 * The merging work was undone by User:taw. See the history pages. I'm not particularly concerned whether there is a separate page for Oberon and Oberon-2 (as for Modula and Modula-2), or whether the pages are merged together. But the 'Oberon-1' terminology HAS to go. Chris Burrows 22:51, 5 November 2006 (UTC)

 * I favour combining the two articles. It was me that merged them - the discussion pages seemed to agree that was the right way to go. User:taw didn't discuss his un-merging before he went ahead with it. I would like to make the following observations:
 * * Oberon(-1) and Oberon-2 are both known as Oberon. Oberon(-1) is no longer interesting, and needs only a historical footnote.
 * * The example code on the Oberon-1 page is actually Oberon-2.
 * * a reader wishing to understand Oberon-2 would need to refer back to the Oberon-1 page as well.
 * OrangUtanUK 14:53, 7 November 2006 (UTC)

Obliq is from Modula-3, not Oberon
Obliq is from Modula-3, not Oberon. —Preceding unsigned comment added by 24.46.21.229 (talk) 23:27, 29 September 2007 (UTC)

Merge?
This has been discussed here and elsewhere, but I'm not sure what came about from the discussion. Can the Oberon-1 and Oberon-2 pages be merged into just an Oberon page? There wasn't really an "Oberon-1", there was just Oberon, and then Oberon-2, and now Oberon-07. Each of the changes/revisions could just have their own sections. Bishopmartin (talk) 01:10, 26 August 2008 (UTC)

I've logged a move request to rename Oberon-1 back to Oberon (programming language). This is consistent with other Wikipedia entries for languages that have ambiguous general-usage equivalents (e.g. Lisp). It also helps to distinguish Oberon the programming language from Oberon the operating system. Chris Burrows (talk) 02:14, 26 August 2008 (UTC)

Origin of Oberon
Is it really named after the moon, and not the moon's namesake, the King of Elves? 88.159.72.252 (talk) 12:23, 5 March 2010 (UTC)

Both. See Page 8 of the Project Oberon book listed in the references. The moons of Uranus and the "king of elfs" are both mentioned.Chris Burrows (talk) 00:11, 6 March 2010 (UTC)

 * According to prof Wirth, the language is named after the moon. Period. All in all this is a rather silly discussion, started by someone who dislikes anything else than his (or her) own language. Jan272 (talk) 06:17, 4 August 2011 (UTC) Jan Verhoeven

Unanswered questions
After reading the article through I find myself lacking a lot of elementary information on the language. I don't know what term Oberon uses for functions (proc?  function?  subroutine?). I don't know if it has record structures or something comparable. I don't know how its objects differ from those in C++, just that they differ. I don't know whether a language feature must be declared before use, as in Pascal. I don't know whether arrays of different sizes are considered different types, one of the most criticized features of Pascal, and which most other modern languages try to circumvent. I don't know if the language supports JAVA-style interfaces. I don't know what the entry point of the programming is -- a "main" routine as in C? Sample source code would help, but the only sample source code I've seen was on this Talk page, not in the main article. In short, this article needs a lot of work. CharlesTheBold (talk) 01:42, 17 June 2012 (UTC)

Both procedures and functions that return a result are called procedures.

Oberon has record structures. Additionally, unlike Pascal and Modula-2 these are extensible and so variant records are no longer required.

Identifiers must be declared before use apart from pointer references.

Name-compatibility is used rather than structure-compatibility as in Pascal and Modula-2. However, the dimensionless 'ARRAY OF ' can be used to allow arrays of arbitrary size to be passed as procedure parameters.

Interfaces are not supported.

On a suitably capable operating system (e.g. the Oberon operating system) any parameterless exported procedure may be an entry point - programs are constrained to just one entry point.

Note that this is an encyclopedia article not a Language Reference. Refer to the external links for more in-depth information about the language. Chris Burrows (talk) 11:50, 17 June 2012 (UTC)

POV
The article seems to me to have a POV problem. It sounds like a booster of the language wrote it.--76.169.116.244 (talk) 03:13, 26 December 2014 (UTC)

title: Talk:Oberon (programming language)


text: User talk:80.55.212.234

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: User talk:80.55.212.234


text:
Oban, New Zealand

Oban is the principal settlement on Stewart Island, the southernmost inhabited island of the New Zealand archipelago. Oban is located on Halfmoon Bay (sometimes used as an alternative name for the town), on Paterson Inlet. It has aircraft connections with Invercargill and a ferry service to Bluff.

The settlement was named after Oban in Scotland, (An t-Òban in Scottish Gaelic, meaning The Little Bay), due to the strong influence Scottish settlers had in the south of early colonial New Zealand.

The island has received a moderate boost of commerce and some millions in government funding since tourism increased markedly after the opening of the Rakiura National Park.

It is possible to see kākā during the day and kiwi during the night in Oban. Efforts have been made to eradicate many of the introduced predators of native birds in Oban, such as stoats and domestic cats, with bigger plans to target possums, three species of rat, as well as hedgehogs.

Demographics
Oban is described by Statistics New Zealand as a rural settlement. It covers 2.59 km2, and had an estimated population of as of  with a population density of  people per km2. It is part of the wider Stewart Island statistical area.

Oban had a population of 300 at the 2018 New Zealand census, an increase of 27 people (9.9%) since the 2013 census, and an increase of 9 people (3.1%) since the 2006 census. There were 165 households, comprising 156 males and 144 females, giving a sex ratio of 1.08 males per female, with 33 people (11.0%) aged under 15 years, 51 (17.0%) aged 15 to 29, 144 (48.0%) aged 30 to 64, and 69 (23.0%) aged 65 or older.

Ethnicities were 92.0% European/Pākehā, 19.0% Māori, 1.0% Pasifika, 1.0% Asian, and 1.0% other ethnicities. People may identify with more than one ethnicity.

Although some people chose not to answer the census's question about religious affiliation, 65.0% had no religion, 26.0% were Christian, 1.0% were Buddhist and 3.0% had other religions.

Of those at least 15 years old, 66 (24.7%) people had a bachelor's or higher degree, and 45 (16.9%) people had no formal qualifications. 39 people (14.6%) earned over $70,000 compared to 17.2% nationally. The employment status of those at least 15 was that 150 (56.2%) people were employed full-time, 42 (15.7%) were part-time, and 3 (1.1%) were unemployed.

Climate
The Köppen-Geiger climate classification system classifies its climate as a mid-latitude oceanic (Cfb). Temperatures are mild to cool year-round, with average high temperatures ranging from 17.2 C in January, the warmest month, to 9.9 C in July, the coolest month. The strong oceanic influence here results in small temperature variations. The diurnal temperature variation is quite low, around 13 - 14 F-change yearlong, and seasonal temperature variation (the difference between the warmest and coldest months) is about 13 F-change. Precipitation averages 58.65 in per year, and is evenly distributed across the year (see climate chart). Year-round, Oban lies in the direct path of mid-latitude cyclones (low-pressure systems, or depressions) arriving from the Southern Ocean, generally moving from southwest to northeast, or west to east. As such, the climate is predominantly windy, cloudy and rainy; clear days and days with calm to minimal wind are rare.

Rakiura Museum
The Rakiura Museum was first opened in 1960 in a converted house. It was reopened in December 2020 in a purpose-built $3 million building in December 2020. it contains artifacts and displays including the history of whaling and sealing around Stewart Island, boat building, Maori settlement and natural history of Stewart Island.

Education
Halfmoon Bay School / Te Kura o Rakiura caters for years 1 to 8 with a roll of students as of  The school was established in 1874.

Oban Presbyterian Church
The Oban Presbyterian Church was built in 1904. Electric lighting was installed in 1957. it is located on Kamahi Road and overlooks Halfmoon Bay. The church did not have a resident minister in 2023 but has regular visiting preachers.

St Andrews Anglican Church
St Andrews Anglican Church is situated at 10 Excelsior Road, Oban. Prince Harry visited St Andrews in 2015.

title: Oban, New Zealand


text:
Imja Tse

Imja Tse, better known as Island Peak, is a mountain in Sagarmatha National Park in the Himalayas of eastern Nepal. The peak was named Island Peak in 1953 by members of the British Mount Everest expedition because it appears as an island in a sea of ice when viewed from Dingboche. The peak was later renamed in 1983 to Imja Tse but Island Peak remains the popular choice. The peak is actually an extension of the ridge coming down off the south end of Lhotse Shar.

The southwest summit of Imja Tse was first climbed in 1953 as part of a training exercise by a British expedition that went on to summit Mount Everest. The team that climbed Imja Tse comprised Tenzing Norgay, Charles Evans, Alfred Gregory, Charles Wylie and seven other Sherpas. The main summit was first climbed in 1956 by Hans-Rudolf Von Gunten and two unknown Sherpas, members of a Swiss team that went on to make the second ascent of Everest and the first ascent of Lhotse.

Climbing route

To climb Island Peak, one has the option of starting from a base camp at 5087 m called Pareshaya Gyab and starting the climb between 2 and 3 A.M. Another popular option is to ascend to High Camp at around 5600 m to reduce the amount of effort and time needed for summit day. However, an adequate water supply and concerns about sleeping at a higher altitude may dictate starting from base camp. Base camp to high camp is basically a hike but just above high camp, some rocky steps require moderate scrambling up through a broad open gully. At the top of the gully, glacier travel begins and proceeds up a steep snow and ice slope. From here, fixed ropes may be set up by the guides for the strenuous ascent of nearly 100 m to the summit ridge. The climb to the summit is somewhat difficult due to steep climbing. On top, while Mount Everest is a mere ten kilometres away to the north, the view is blocked by the massive wall of Lhotse, towering 2300 m above the summit.

Headwall crevasse
A substantial crevasse along most of the headwall leading to the summit ridge has sometimes caused teams to turn back. In April 2009, the Nepal Mountaineering Association tasked the Nepal Mountaineering Instructors' Association with installing stairs (ladders) at the crevasse. As of the 2016 fall climbing season, a 5-metre high fixed aluminum ladder is being used to cross the crevasse.

title: Imja Tse


text:
User:Matt Toups

I currently live in Pittsburgh, Pennsylvania. I am originally from the Carrollton neighborhood of uptown New Orleans.

I do volunteer work with WRCT radio in Pittsburgh and the Independent Media Center network. (IMC wiki user page) Recently Rustbelt Radio has been a major radio project I have worked on.

My Contributions to Wikipedia

title: User:Matt Toups


text:
Talk:Imja Tse

Coordinates
The following coordinate fixes are needed for

—122.56.168.229 (talk) 01:38, 17 March 2023 (UTC)
 * You haven't said what you think is wrong with the coordinates in the article, and they appear to be correct. If you still think that there is an error, you'll need to supply a clear explanation of what it is. Deor (talk) 12:10, 17 March 2023 (UTC)

title: Talk:Imja Tse


text:
Talk:University of California, Los Angeles

Ranking information in the lede
An unregistered editor is insisting that the lede of this article include the following phrase: "...is frequently ranked among the best universities in the world by major college and university rankings. "

First, rankings from a single source in a single year cannot possibly substantiate a claim about being "frequently" ranked by "major college and university rankings." Something done once cannot be frequent and single ranking cannot be described as plural. Second, there is a a project-wide consensus about the inclusion of rankings and prestige in the lede of articles about colleges and universities and this single source comes nowhere close to meeting that consensus.

If an editor believes that this kind of information should be in the lede of this article, they are strongly encouraged to review WP:HIGHEREDREP and provide sources that meet that consensus. ElKevbo (talk) 16:34, 29 April 2023 (UTC)

 * Or at least sign up, wouldn't you think? 🤷♂ – AndyFielding (talk) 12:41, 20 May 2023 (UTC)
 * The mention of UCLA's reputation in the lead section is appropriate pursuant to WP:HIGHEREDREP, which states that "only if a reputation is exceptionally good or bad or disputed is it such an important fact as to be noted in the lead section of an article." UC Berkeley's page mentions its ranking in the lead section, and as UCLA has tied with UC Berkeley as the number one public institution in the US for years, it therefore has an "exceptionally good" reputation worth noting in the lead section. This is supported by the US News and Times Higher Education rankings provided. It is not the case that UCLA's number one ranking has only maintained for a single year. It has been at number one for six years. Other sources can be cited at the end of the claim to substantiate UCLA's reputation, which is by any serious metric, "exceptionally good" (refer to WP:HIGHEREDREP). Geogrk (talk) 01:42, 16 August 2023 (UTC)

 * I would not object to a brief statement in the lede that complies with WP:HIGHEREDREP by citing the kinds of high quality sources that are necessary to support that kind of statement in the article's lede. In particular, citing a handful of rankings that you personally select to support a broad, sweeping claim is not acceptable; if you think the article needs a broad statement in the lede, you need to provide strong sources that explicitly support the claim. The sources used in the Berkeley article and discussed in that article's Talk page can provide some really good guidance. ElKevbo (talk) 01:54, 16 August 2023 (UTC)
 * Noted, I will attempt this later. Thank you. Geogrk (talk) 01:58, 16 August 2023 (UTC)

Greek life and school traditions
This section is unusual for an article about big universities. The contents of the Greek part are unreferenced and since it is just a rote list of various fraternities and sororities without any further detail, I question whether there is any useful information being shared here. The school traditions seem really anecdotal and most of them are unsourced. I propose deletion. -- Melchior2006 (talk) 18:48, 4 May 2023 (UTC)
 * Since no one chimed in on this one, I will go ahead and streamline. --Melchior2006 (talk) 06:53, 8 May 2023 (UTC)
 * Yay! I mean, rah! – AndyFielding (talk) 12:42, 20 May 2023 (UTC)

Scandals
There are two sub-sections in the 'History' section about scandals. In other university pages, there's a separate section for university related scandals. So I propose to create a separate section called 'Scandals' and transfer the scandal related contents in that section, instead of putting them in the 'History' section. Ragnarvrollo (talk) 04:35, 5 May 2023 (UTC)

 * That is a very good suggestion. Thank you for the initiative. -- Melchior2006 (talk) 06:23, 5 May 2023 (UTC)

 * No thanks. In general, many Wikipedia editors do not believe that "controversy" sections in articles are appropriate. Our advice for college and university articles recommends that we "place controversies and other events into their proper historical context." That advice also recommends that this kind of information be placed into the "History" section. It's just usually bad practice to divorce controversies from broader context that readers needs to understand them. ElKevbo (talk) 11:55, 5 May 2023 (UTC)
 * That's odd… In WP's bios, you see controversies split off into their own sections all the time. Maybe there isn't as much of a tabloid effect with institutions. – AndyFielding (talk) 12:47, 20 May 2023 (UTC)


text:
ISO/IEC 12207

ISO/IEC/IEEE 12207 Systems and software engineering – Software life cycle processes is an international standard for software lifecycle processes. First introduced in 1995, it aims to be a primary standard that defines all the processes required for developing and maintaining software systems, including the outcomes and/or activities of each process.

Revision history
ISO/IEC/IEEE 12207:2017 is the newest version, published in November 2017. The IEEE Computer Society joined directly with ISO/IEC JTC 1/SC 7/WG 7 in the editing process for this version. A significant change is that it adopts a process model identical to the ISO/IEC/IEEE 15288:2015 process model (there is one name change, the 15288 "System Requirements Definition" process is renamed to the "System/Software Requirements Definition" process). This harmonization of the two standards led to the removal of separate software development and software reuse processes, bringing the total number of 43 processes from 12207 down to the 30 processes defined in 15288. It also caused changes to the quality management and quality assurance process activities and outcomes. Additionally, the definition of "audit" and related audit activities were updated. Annex I of ISO/IEC/IEEE 12207:2017 provides a process mapping between the 2017 version and the previous version, including the primary process alignments between the two versions; this is intended to enable traceability and ease transition for users of the previous version.

Prior versions include:
 * ISO/IEC 12207:2008, which was published in February 2008
 * ISO/IEC 12207:1995/Amd 2:2004, an amended version of the prior, published in November 2004
 * ISO/IEC 12207:1995/Amd 1:2002, an amended version of the prior, published in May 2002
 * ISO/IEC 12207:1995, the first iteration, published in July 1995; originally was divided into five primary processes (acquisition, supply, development, operation, and maintenance), with eight supporting and four organizational life cycle processes

IEEE versions
Prior to the IEEE Computer Society formally joining the editing process (becoming a major stakeholder) for the 2017 release, the IEEE maintained its own versions of ISO/IEC 12207, initially with modifications made jointly with the Electronic Industries Alliance (EIA). With the 2008 update came a "shared strategy of ISO/IEC JTC 1/SC 7 and the IEEE to harmonize their respective collections of standards," resulting in identical standards thereon, but with slightly different names. Those IEEE versions included:

 * IEEE Std. 12207-2008: "integrates ISO/IEC 12207:1995 with its two amendments and was coordinated with the parallel revision of ISO/IEC 15288:2002 (System life cycle processes) to align structure, terms, and corresponding organizational and project processes"; superseded by ISO/IEC/IEEE 12207:2017
 * IEEE/EIA 12207.2-1997: "provides implementation consideration guidance for the normative clauses of IEEE/EIA 12207.0"; superseded/made obsolete by IEEE Std. 12207-2008, which was then superseded by ISO/IEC/IEEE 12207:2017
 * IEEE/EIA 12207.1-1997: "provides guidance for recording life cycle data resulting from the life cycle processes of IEEE/EIA 12207.0"; superseded by ISO/IEC/IEEE 15289:2011, which was then superseded by ISO/IEC/IEEE 15289:2017
 * IEEE/EIA 12207.0-1996: "consists of the clarifications, additions, and changes [to ISO/IEC 12207:1995 for industry implementation] accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Alliance (EIA) as formulated by a joint project of the two organizations"; superseded by IEEE Std. 12207-2008, which was then superseded by ISO/IEC/IEEE 12207:2017

It's also worth noting that IEEE/EIA 12207 officially replaced MIL-STD-498 (released in December 1994 ) for the development of DoD software systems on May 27, 1998.

Processes not stages
The standard establishes a set of processes for managing the lifecycle of software. The standard "does not prescribe a specific software life cycle model, development methodology, method, modelling approach, or technique.". Instead, the standard (as well as ISO/IEC/IEEE 15288) distinguishes between a "stage" and "process" as follows:

 * stage: "period within the life cycle of an entity that relates to the state of its description or realization". A stage is typically a period of time and ends with a "primary decision gate".
 * process: "set of interrelated or interacting activities that transforms inputs into outputs". The same process often recurs within different stages.

Stages (aka phases) are not the same as processes, and this standard only defines specific processes - it does not define any particular stages. Instead, the standard acknowledges that software life cycles vary, and may be divided into stages (also called phases) that represent major life cycle periods and give rise to primary decision gates. No particular set of stages is normative, but it does mention two examples:

 * The system life cycle stages from ISO/IEC TS 24748-1 could be used (concept, development, production, utilization, support, and retirement).
 * It also notes that a common set of stages for software is concept exploration, development, sustainment, and retirement.

The life cycle processes the standard defines are not aligned to any specific stage in a software life cycle. Indeed, the life cycle processes that involve planning, performance, and evaluation "should be considered for use at every stage". In practice, processes occur whenever they are needed within any stage.

Processes
ISO/IEC/IEEE 12207:2017 divides software life cycle processes into four main process groups: agreement, organizational project-enabling, technical management, and technical processes. Under each of those four process groups are a variety of sub-categories, including the primary activities of acquisition and supply (agreement); configuration (technical management); and operation, maintenance, and disposal (technical).

Agreement processes
Here ISO/IEC/IEEE 12207:2017 includes the acquisition and supply processes, which are activities related to establishing an agreement between a supplier and acquirer. Acquisition covers all the activities involved in initiating a project. The acquisition phase can be divided into different activities and deliverables that are completed chronologically. During the supply phase a project management plan is developed. This plan contains information about the project such as different milestones that need to be reached.

Organizational project-enabling processes
Detailed here are life cycle model management, infrastructure management, portfolio management, human resource management, quality management, and knowledge management processes. These processes help a business or organization enable, control, and support the system life cycle and related projects. Life cycle model management helps ensure acquisition and supply efforts are supported, while infrastructure and portfolio management supports business and project-specific initiatives during the entire system life cycle. The rest ensure the necessary resources and quality controls are in place to support the business' project and system endeavors. If an organization does not have an appropriate set of organizational processes, a project executed by the organization may apply those processes directly to the project instead.

Technical management processes
ISO/IEC/IEEE 12207:2017 places eight different processes here:

 * [Project planning]
 * Project assessment and control
 * Decision management
 * Risk management
 * Configuration management
 * Information management
 * Measurement
 * Quality assurance

These processes deal with planning, assessment, and control of software and other projects during the life cycle, ensuring quality along the way.

Technical processes
The technical processes of ISO/IEC/IEEE 12207:2017 encompass 14 different processes, some of which came from the old software-specific processes that were phased out from the 2008 version.

The full list includes:

 * Business or mission analysis
 * Stakeholder needs and requirements definition
 * Systems/Software requirements definition
 * Architecture definition
 * Design definition
 * System analysis
 * Implementation
 * Integration
 * Verification
 * Transition
 * Validation
 * Operation
 * Maintenance
 * Disposal

These processes involve technical activities and personnel (information technology, troubleshooters, software specialists, etc.) during pre-, post- and during operation. The analysis and definition processes early on set the stage for how software and projects are implemented. Additional processes of integration, verification, transition, and validation help ensure quality and readiness. The operation and maintenance phases occur simultaneously, with the operation phase consisting of activities like assisting users in working with the implemented software product, and the maintenance phase consisting of maintenance tasks to keep the product up and running. The disposal process describes how the system/project will be retired and cleaned up, if necessary.

Conformance
Clause 4 describes the document's intended use and conformance requirements. It is expected that particular projects "may not need to use all of the processes provided by this document." In practice, conforming to this standard normally involves selecting and declaring the set of suitable processes. This can be done through either "full conformance" or "tailored conformance".

"Full conformance" can be claimed in one of two ways. "Full conformance to tasks" can be claimed if all requirements of the declared processes' activities and tasks are met. "Full conformance to outcomes" can be claimed if all required outcomes of the declared processes are met. The latter permits more variation.

"Tailored conformance" may be declared when specific clauses are selected or modified through the tailoring process also defined in the document.

title: ISO/IEC 12207


text:
Kikunae Ikeda

Kikunae Ikeda (池田 菊苗) was a Japanese chemist and Tokyo Imperial University professor of chemistry who, in 1908, uncovered the chemical basis of a taste he named umami. It is one of the five basic tastes along with sweet, bitter, sour and salty.

Education
Ikeda graduated in 1889 from Tokyo Imperial University in chemistry. In 1891, he became a professor at the Higher Normal School of Tokyo, in 1896 he became an associate professor at Tokyo Imperial University. From 1899, Prof. Ikeda studied in Germany for two years at the laboratory of Prof. Friedrich Wilhelm Ostwald at the University of Leipzig, which was then the center of physical chemistry. After a brief stay in London, he returned to Tokyo in 1901 and became a full professor in chemistry at Tokyo Imperial University.

Discoveries
In 1907 at the Tokyo Imperial University in Japan, Ikeda was eating dinner with his family when he suddenly stopped. That day the dashi broth in his soup was more delicious than normal; after stirring a few times he realized the difference was the umami flavor from the addition of kombu, a species of brown macroalgae and flakes of fish known as katsuobushi. He understood that kombu was the secret to that flavor, and from that day on he studied the chemical composition of kelp. Some noted that the taste of the umami is similar to the flavor of the haute cuisine that the French chef Auguste Escoffier created.

By 1908, he had isolated brown crystals of glutamic acid (glutamate) which conveyed the characteristic flavor. The chemical monosodium glutamate (MSG) is the chemical basis for the umami flavor. He chose to call it. By 1909 he had developed a process for mass-producing MSG. He was able to extract MSG from wheat and defatted soybean, and patented the process for its manufacture. Today, MSG is mass-produced from fermented cornstarch, sugar cane, molasses, or beet. His Ajinomoto Co., Inc. currently employs over 32,000 people. With this method the global production of MSG increased rapidly. MSG ranks today as one of the top flavor enhancers after salt and pepper.

Kikunae Ikeda also studied other foods to see if they contained umami, and confirmed that glutamate was responsible for part of the flavor of meat, seaweed and tomatoes. He believed that humans likely developed a taste for glutamate because it signaled the presence of proteins.

Praise
On 18 April 1985, the Japan Patent Office selected him as one of Ten Japanese Great Inventors.

title: Kikunae Ikeda