16 ms·

Brooks, Wirth and Go

258 points by kiyanwang 5y ago

ch_123 5y ago
Nitpick: "[The System/360] was the worlds first real programmable mainframe computer, opening up the notion that computers could be reprogrammed to suit new problems instead of being replaced by newer models." The S/360 was by no means the first programmable computer. Rather, it was the first computer product line where all systems were compatible with each other, and where future models would all retain backwards compatibility. The selling point was that you would not have to rewrite your code (or make significant changes) if you wanted to move to a larger system.
- Koshkin 5y ago
  That’s some nit that you picked! What else might be there, I wonder now.
johndoe0815 5y ago
Software complexity also helps to establish or maintain the predominance of large corporations on the market. In contrast, a simple software system can be reimplemented by a small team or even a single person, so there is more competition. This is not only demonstrated by Wirth's systems, but also by several 7th edition Unix clones of the 80's [1-4] as well as current ones [5] and also reimplementations of the classic MacOS [6]. Back in the 1980s, operating systems and compilers were often seen as the most complex pieces of software. Nowadays, web browsers include (and reimplement) large parts of an OS and compiler and are probably even more complex than a current OS such as Linux or a current compiler such as clang/LLVM. Only rich (or well funded) companies such as Google, Apple and the Mozilla foundation can afford to build a browser today that can be used to access current web pages. So a central question is if we can turn back times and make software more simple again. Maybe this ship has already sailed - but it can't hurt to try. From experience with my students, it is extremely satisfying for them to build a complete system from scratch instead of mostly copying and pasting library calls or StackOverflow code snippets. Thus, I try to enable my students to experience this sense of achievement. They will probably never get the chance to do something similar in their later career in industry. [1] One Man Unix for 68k - http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html [2] Uzix for Z80 (link to the MSX port) - http://uzix.sourceforge.net http://uzix.sourceforge.net [3] Coherent Unix - https://en.wikipedia.org/wiki/Coherent_(operating_system) https://en.wikipedia.org/wiki/Coherent_(operating_system) [4] Minix - https://www.minix3.org https://www.minix3.org [5] Alan Cox' Fuzix - https://github.com/EtchedPixels/FUZIX https://github.com/EtchedPixels/FUZIX [6] Ardi Executor - https://en.wikipedia.org/wiki/Executor_(software) https://en.wikipedia.org/wiki/Executor_(software)
dmitriid 5y ago
Too many leaps of faith and too many appeals to authority. Wirth's quest for one true small language led to an array of languages that only show that no, you can't have too simple of a language, or you will end up with a system that is too complex because of the language. The ones I remember from a very long discussion a decade or so ago: - the meaningless distinctions between functions and procedures - the very many iterations on loop constructs (in some of his languages there are three loop constructs with different rules. For example, you can break early from only one of them) IIRC in Oberon BlackBox the necessity for complexity is just swept under the rug where system modules are allowed operations that are not available to user modules (IIRC it was function overloading and exceptions? I could be wrong). In many ways Go is following Wirth's path of confusing language complexity, problem complexity and solution complexity. Yes, you can a wonderfully simple language with very few constructs. But if you have to write thousands of lines of boilerplate code to handle a problem, you haven't solved complexity. You've offloaded it onto the programmer. As for "OMG, Wirth wrote an OS in Oberon, he was onto something"... Menuet OS is written in assembly, fits on a floppy disk, and can boot near-instantly on a 200 Mhz processor [1]. Does this mean we should ditch all the bad complex languages and switch to assembly? Though I agree: most of present-day software is extremely bloated and inefficient. [1] https://en.wikipedia.org/wiki/MenuetOS https://en.wikipedia.org/wiki/MenuetOS
- zetalyrae 5y ago
  >Wirth's quest for one true small language led to an array of languages that only show that no, you can't have too simple of a language, or you will end up with a system that is too complex because of the language. The ones I remember from a very long discussion a decade or so ago: >- the meaningless distinctions between functions and procedures >- the very many iterations on loop constructs (in some of his languages there are three loop constructs with different rules. For example, you can break early from only one of them) Arguably the problem here is Wirth didn't go far enough. You can design a simpler version of, say, Modula-3 by unifying statements and expression as in ML, and replacing the multiple iteration constructs with recursion, and guaranteeing tail recursion.
  - masklinn 5y ago
arkj 5y ago
>> You have to completely comprehend your idea in order to fully realize it. This is a gem.
- emmanueloga_ 5y ago
  Corollary: you will fully comprehend your idea once you have fully realized it :-). My point is that iterative implementation often helps to better understand the problem, I think.
- vidarh 5y ago
  Indeed. Wirth's insistence on only adding those things to his language he fully understood was one of the things that inspired me to start writing a Ruby compiler (long dormant in an "almost self-compiling but wildly incomplete" state; I tinker with it every now and again but haven't had time since May judging by my last notes) - it struck me that fully understanding the true complexity of Ruby as a language required understanding how to implement it efficiently. I love using Ruby, but it's an absolute nightmare of a language to implement (and far worse to compile), and it's if anything driven home an appreciation for Wirth's insistence on simplicity.
- Koshkin 5y ago
  The word “realize” has two meanings, one is “understand” and the other (perhaps less used), “make real” or “implement.” (I would still disagree with the sentiment - better understanding often comes during implementation.)
erik_seaberg 5y ago
> You cannot reduce the complexity of your problem by increasing the complexity of your language. This strikes me as backwards. There’s a certain amount of irreducible complexity in any requirements, and every commonplace problem the language refuses to solve is one more problem for me to face with no help. Nearly every feature that makes a language more concise and powerful (reentrant functions, higher-order functions, tail recursion, continuations, dynamic dispatch, multiple dispatch, garbage collection, sum and product types, pattern matching, exceptions, concurrency, laziness, macros) makes it harder to specify and implement, but reusing a heavily tested implementation that everyone knows is always better than trying to roll my own. > Language is (comparatively) easy to pick up. This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. It’s like boasting that your toolbox is easy to carry, because it’s empty. > Deploy by running a single executable. This is not a good thing. It guarantees you can’t reuse any code provided by the platform. Static linking was a problem that was solved in the 1980s, and being able to choose it is always better than being forced into it. Anyway, Go does have a GCC-based toolchain with a normal linker, even if proponents prefer the one that reinvents everything incompatibly. > Being stuck in the 70s means no breaking changes since flared pants. I actually agree that languages should commit to “if you ask for the 2021 semantics that’s exactly what you get now and forever,” but any language can do that, we don’t have to settle for weak ones.
- zetalyrae 5y ago
  >This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. I disagree with this. There are many languages that are perfectly productive which are reducible to a very small core: Haskell, Standard ML, OCaml, Modula-2/3. The size of the ecosystem is an extrinsic property to the language. Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. Very rarely does language complexity buy you anything except painful surprises or obfuscated code contest entries. For example: Rust is a much simpler language than C++ and you can use it to do essentially anything reasonable you'd want to do in C++.
  - 5y ago
lifthrasiir 5y ago
This article wants to portray Go as a "small" language, but the batteries-included standard library is definitely a part of the language and Go is nothing but a small language by this measure. It is not hard to have just a large standard library (see Python), but a coherent one is difficult and requires a ton of efforts---with a large corporate backing in this case. By having a large and coherent standard library Go effectively swept the complexity under the carpet. Which is fine while it lasts.
- jstx1 5y ago
  > By having a large and coherent standard library Go effectively swept the complexity under the carpet. Which is fine while it lasts. Are you implying that it's a bad thing? Complex things that are frequently used got abstracted away so they can be easily reused - sounds great to me. Why wouldn't it last?
  - lifthrasiir 5y ago
    It is not necessarily bad, but a language with a large standard library isn't small. The article prominently features the benefit of small languages, which (I only agree partly but notwithstanding) wouldn't apply to a language with a large standard library no matter the size of the core language. Therefore the article's final claim is invalid, no matter it actually turns out to be true or not.
- solaxun 5y ago
  I'm not sure how the size of a standard library has any bearing on the size and perceived complexity of the language. To me, it's about how many language features/keywords/constructs etc. one must keep in their head to effectively write code, including writing the standard library. I'd rather have a language with a very small core and an extensive set of libraries implemented with that core than one with a large core that tries to handle everything with features. There's something to be said about comprehensibility of libraries written in a language with a small and focused core, as well.
  - 5y ago
nickd2001 5y ago
Perhaps someone will answer this related Q.. Having coded in Python for years, I'm underwhelmed by claims of Go's simplicity. Python, with its batteries included, seems to me simpler to code in and for understanding existing code, and easier to produce more maintainable code in as far as I can see. (this may partly reflect my prior experience to be fair) When I looked at Go, it looks like one has to do acrobatics and write a load of code to get around missing basic libraries and features in the language. So, I can see Go is useful for being very lightweight, and a good replacement for C++ for many things, but as for it being simple.... well, really? I guess does "simple" mean, relative to the likes of C++ ?
- emmanueloga_ 5y ago
  There's a talk called "Simple made Easy" by Rich Hickey (you can find it in YouTube) that talks about the difference between simple and easy in software development. Under those definitions, I agree some things in Go are not necessarily as easy to solve as in Python, but Go is definitely simpler.
  - tharne 5y ago
    That talk should be at the top of every programmer's list. At the risk of sounding cliché, it actually will change how you think about program design.
    - Calamitous 5y ago
      Most of Rich Hickey's talks fall into that category.
  - Scarbutt 5y ago
    You have it backwards, Go gives you the illusion that is easy (easy to start with, quick to start coding something in it) but is no simple. Writing simple systems is hard and Go works against you here.
- luxurytent 5y ago
  There's a few notes in the article that touch on why Go is simple. FWIW, Go comes with plenty of batteries included and as a day-time Go developer, most of what we build doesn't require external libraries (generally logging, database modules, etc. are external) Also what makes Go simple? This (From the article): > If it worked ten years ago, it works now. I have a collection of blog posts from the Go blog and other sources which I revisit from time to time and many are from indeed, ten years ago. Less cognitive overhead on figuring out what's from version x or y, if it's been deprecated, etc.
dgb23 5y ago
I really like Go and respect the authors and maintainers of the language. It is well designed and achieves its goals exceptionally well. The author of this article is right: Give it a Go! You'll learn it quickly and will appreciate having learned it, there are many, very considerate design decisions to discover, ranging from language implementation, tooling and the standard library. I'm sometimes jealous of Go's users, the language is very readable, light and refreshingly straight forward. That said, I cannot bring myself to use it (anymore). The language doesn't scale with my ability and in some sense seems almost patronizing. I'm not a particularly good programmer, but I'm experienced enough that I feel held back by languages like Go. When you are used to more power, expressiveness and clarity, then you just miss it at every step of the way. On one hand the language doesn't let me encode higher level thinking directly (relational, functional, domain specific...) but I have to act as a compiler. And vice versa it doesn't expose the low level control that one would want to squeeze out performance and minimize resource usage either. Again, Go still feels attractive in some sense, and I wish I had a reason to use it more, but I can't find it.
- t8sr 5y ago
  I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming for 20 years. I think most programmers go through a phase, after 2-5 years of experience, where they get really into higher-level thinking. Everything is written according to a mantra like TTD, functional design, or everything-is-an-object, and they spend most of their complexity budget on abstractions. The code people write in that stage of their careers looks to them like an improvement over the simpler concepts they started with, it ends up being so much technical debt 12 months later, because almost nobody is good at predicting which higher-level concepts you are going to need, and by the time you realize you were wrong, it’s too expensive to remove them. It’s hard for a language to encourage this kind of you-ain’t-gonna-need-it thinking without seeming patronizing, but I promise you that the next 10 years of your career will change your mind. (I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.)
  - 5y ago
mongol 5y ago
> Even cellphones are powerful enough to calculate every computation humanity had computed by the 20th century put together. What does he mean? A single cellphone? Or all cellphones in the world combined?
- carnitine 5y ago
  A single cellphone.
smikhanov 5y ago
> Now, perhaps OSX is more feature complete than Oberon, > but certainly not by a factor of ~40 000X. Not sure why the author is so certain of that. Isn't that conceivable that a modern industrial-grade OS is 40 000 times more feature rich compared to its academic counterpart from 35 years ago?
- geodel 5y ago
  No, it is not conceivable to me as user. Though it could be for product managers creating release notes every month from thousands of GitHub issues or JIRA tickets resolved and listing features.
eesmith 5y ago
> "it has taken more than two weeks for the result to come back" That sounds exceptionally long for that era. I didn't easily find hard numbers. https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newland-J-1981-PhD-Thesis.pdf https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newl... (in a student environment in 1981) shows a turn-around from 20 minutes to 6 hours. See page 123 table 4.1. Also in a student environment, early 1970s, https://ir.library.oregonstate.edu/downloads/8g84mp855 https://ir.library.oregonstate.edu/downloads/8g84mp855 "Batch turnaround time averages somewhat less than a hour with a range of one-half to three hours." At The Rand Corporation in 1974, "Normal batch turnaround for jobs run during the day had averaged 30 minutes for quite some time." - https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 More generically, "Turnaround time may take minutes, hours, days or even more than a week before completed outputs are returned in response to job requests." - https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 . Two weeks therefore sounds very much like an outlier. > "Meanwhile, another engineer programming in Smalltalk and Interlisp is writing and running their implementation directly against a system console." Or BASIC, developed in in 1964 along side with the Dartmouth Time Sharing System. For example, by 1975, the HP 2000F was "the first minicomputer to offer time-shared BASIC", and it supported Fortran and other languages besides BASIC. https://en.wikipedia.org/wiki/HP_2100#HP_2000 https://en.wikipedia.org/wiki/HP_2100#HP_2000 Python is the modern BASIC. Also, note that interactively starting a long job (eg, compiling a large FORTRAN program) only saves the manual batch submission overhead. The compilation might still take time to run, especially if it requires system resources that aren't currently available so is still put into a queue. > Forget about a “10X programmer”, how about a “10 000X programmer”? That is not supported by the research. See https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 for one summary of several papers comparing batch vs. online computing. The Grant-Sackman paper is the only of those using professional programmers instead of students. The summary is "Time-sharing requires fewer man-hours to debug programs for highly experienced programers than a simulated batch system with a two-hour turnaround time." (19.3 hours instead of 31.2) and "Individual performance differences in 3 highly experienced group of programers are considerably larger than observed system differences between time-sharing and batch processing"
- 5y ago
lazyjones 5y ago
Unfortunately, large parts of the IT industry thrive on excess complexity in software and languages. Which is probably why Wirth's languages went out of fashion at some point in the early 1990's. As far as Go is concerned, it really started out well, but with generics it finally broke ties with Wirth's spirit because adding them to the language makes it unnecessarily bloated and will never reduce the complexity of your problems.
zija 5y ago
From top popular language, say from https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/ https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2..., only Go and Swift/ Objective-C are languages with static typing, compiled to native tool chain . And Swift are very apple centric. This have huge impact for go popularity. Alternative to Go: - java and JVM language are heavy gorilla languages that's need more resources/ no value types. graal native is not straightforward alternative. - C# is good alternative, but again jitted, and there are no alternative for Microsoft products in open source community,people choose go as default alternative to java few years ago..
- Zababa 5y ago
  Did you forget about C++ and Rust?
  - zija 5y ago
    No, i like Rust very much. But Rust require from me to deep dive with language, it's not productive language, it's correct from start to end language. Language with optional GC, value types like Nim or D are better for small hobby projects. But community and library ecosystem and tooling are weak. On other hand there are Ocaml and F#. But Ocaml for windows is weak, community is small etc F# inherits problems from c#
    - Zababa 5y ago
      That's a fair point, but I don't find Rust really harder to use than Go for small hobby projects. Swift is nice as a language but has a huge lack of libraries.
    - AnimalMuppet 5y ago
      OK, but this: > From top popular language, say from https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2 https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2..., only Go and Swift/ Objective-C are languages with static typing, compiled to native tool chain is still false.
- 5y ago
mongol 5y ago
Would be interesting to compare the success of languages, by comparing those that were born in academia vs born in industry. For example, Python I believe can be said to be born in academia, while Java in industry. Obviously, industry-born languages still borrow from academia, but what have been the extra ingredients that made them more successful (=more used) than "obscure" languages that remained in academia?
pjmlp 5y ago
> Having created PASCAL, MODULA and MODULA-2, Wirth set out to develop the OBERON family of languages in order to build his operating system on his workstation. This is not quite true. Modula and Modula-2 originated from Wirth's first sabattical at Xerox PARC, where he got acquaited with Mesa and the XDE development environment, back at ETHZ he created Modula/-2 and the Lillith OS. On his second sabattical at Xerox PARC, Mesa had evolved into Mesa/Cedar, and that was the genesis for Oberon, his second workstation OS. Also although I appreciate Wirth's work, for me the best languages were Modula-2, and Active Oberon, while the best Pascal dialect is indeed what Apple and Borland did with it. I am not a fan of Wirth's later pursue for the minimalist GC systems language design.
fredrikholm 5y ago
Author here. This thread made my day. To the people who have commented, thank you. I seldom get to interact with SE people who enjoy their craft, and to see that so many have not only read my post but spent time writing out (dis)agreements brings a smile to my face. Some people have pointed out some historical inaccuracies, to which I'm grateful. Most of these points are taken from random sources I've consumed over the years, including for instance the two-week-turnaround, which was a hand-wavy quote from Brooks (video interview) for which I don't remember the source. Using it was for effect, perhaps a bit too eager on my part. I'm new to writing, and by extension, putting my thoughts to paper. This blog entry was written to concretize my thoughts on this subject, as I've found that writing them down helps to clarify them a lot, and to practice my English (non-native speaker). On the subject of minimalism: I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today, and what was standard then is outdated (or even deprecated) now. Throw in some IDEs, frameworks, licenses etc. and the amount of man-hours lost to auxiliary ad-hoc work has been both draining and expensive (for our customers). Switching several projects to Go mitigated this almost immediately, where the return of investment combined with the novelty factor has lifted the spirits of not only me but the people I've worked with. Going back is (for me) out of the question, at least for the time being. Happy to see people sharing their thoughts on this. Cheers :)
- dmitriid 5y ago
  > I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today Java, C# and Javascript are obsessive about backwards compatibility (one of the reasons Java's changes to the language are moving so slow). There's nothing magical about Wirth's languages or Go. What worked two years ago will be broken today, and the language has very little to do with it. > Switching several projects to Go mitigated this almost immediately As in: you haven't run into things that are broken yet.
  - fredrikholm 5y ago
    > Java, C# and Javascript are obsessive about backwards compatibility This might be true for Java, but this has not been my experience for the other two. NET especially. Incrementally migrating from 4.6.* to CORE3 has been challenging, even when we've had external (expert) .NET consultants to help us. > There's nothing magical about Wirth's languages or Go. I don't think so either! On the contrary, they're everything but magical. > What worked two years ago will be broken today, and the language has very little to do with it. Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. On the contrary, looking at code examples and best practices from 2011 look exactly the same. Writing Swift, anything older than 2019 made me sweat. > As in: you haven't run into things that are broken yet. Longest record so far! :)
Simplicitas 5y ago
You had me at "Deploy by running a single executable"
candyman 5y ago
After a few decades away from programming I got back into it some and decided that Python was the easiest and closest to the languages I was fairly fluent in back in the old days. I did write a lot of Pascal code at one point and after going through the "give it a Go" link I can see the appeal. It looks like a good tool for some things. I look forward to working with it some more. Thanks for your article. I have always enjoyed Brooks and Wirth so that's some good "geek clickbait" that I can't resist!
jksmith 5y ago
It's unfortunate that few here will have used M2 in a commercial setting. Well crafted M2 code led to feelings of deep satisfaction. It was like codification of quality.
zepto 5y ago
I love the piece in general, but one statement stands out to me: > Now, perhaps OSX is more feature complete than Oberon, but certainly not by a factor of ~40 000X. I am not at all sure that this is true. Unix alone has a vast feature set. Then consider just the features connected with something like displaying type, or accessibility. OS X is complex because it has accreted a large collection of messy human requirements. > Something was lost along the way. This is 100% true. Even to me, as someone who thinks Apple does good work, OSX doesn’t feel like a general purpose computer in the way that someone like Oberon or an Alto running smalltalk does. The Kay quote comes to mind: “ Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.” It a bit unfair to Apple. There is structural integrity to OSX, but it’s like a civil engineering project where the integrity is gradually being retrofitted over time.
- scroot 5y ago
  > There is structural integrity to OSX, but it’s like a civil engineering project where the integrity is gradually being retrofitted over time. Despite the engineered "user-friendliness" of the OS, it still suffers from a simple problem, which is this: how can a user make a button for themselves? There are buttons all over the system. Users know how to interact with them. But the only consistently supported way to make a "real" button is to learn a full low-level language and all the dev tools and classes that go with it. That is not good design.
  - zepto 5y ago
    I agree with the sentiment, and indeed I’ve been disappointed with the rate of progress in this area by Apple, however they clearly are slowly moving in that direction. But to me the question this raises is - do you think anyone has done better, and if so who?
    - scroot 5y ago
      > But to me the question this raises is - do you think anyone has done better, and if so who?. Yes. Apple in the past, for one. When they included Hypercard free with every Macintosh and also began integrating Applescript into the core of their OS, they were taking steps in the right direction. Also, as you mentioned, Smalltalk and similar systems also had a good trajectory in this regard. The incentives and visions of computing have changed drastically since the 80s.
chauhankiran 5y ago
I want to know what author or others think about Elixir? I recently started learning and found it interesting and something totally new than what I know.
- fredrikholm 5y ago
  OP links to my previous entry, 'Why Erlang'[0] near the end! :) 0. https://www.fredrikholmqvist.com/posts/why-erlang/ https://www.fredrikholmqvist.com/posts/why-erlang/
rramadass 5y ago
The main premise of the article seems to be; 'You cannot reduce the complexity of your problem by increasing the complexity of your language.' Disagree; eg. DSLs. Here "Simplicity" is born out of a large array of "Complicated Constructs" in some language. The size of the surface area encompassing the various constructs is directly proportional to the expression of various possible models of computations and thus effective problem solving. This idea is what is behind the Mozart/Oz language (and of course C++ :-)
- d0100 5y ago
  > 'one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.' I think this is also a premise of the article, I don't see that quote as "the main" premise, but just another quote used to explore the overall points presented
  - rramadass 5y ago
    The article is trying to focus on "Simplicity"(in everything?) with Go being the exemplar according to the author. However it confuses two major issues; Simplicity in the Language used for expression vs. Simplicity in the Solution of a Problem. They are two very different things; and the quote you list (by Tony Hoare) actually refers to the latter. Simplicity in the solution of a problem is not to be argued against. This was the main thrust of Wirth's work (see also the book The School of Niklaus Wirth: The Art of Simplicity). But he presupposed that this is only possible by using a "Simple" language. This is what is debatable. I think with the experience that the community has gained now (in terms of volume of software written) we are realizing the need for "Complex" languages/libraries/frameworks.
abeyer 5y ago
> If it worked ten years ago, it works now. As long as it isn't a dependency management system. /s
brundolf 5y ago
I'm a big advocate for simplicity. I think it's one of the most important guiding principles in software engineering. I don't care for Go mostly for reasons unrelated to its simplicity; I have respect for the latter, even for decisions like excluding generics. I think broadly that we need more simplicity-focused languages. However, I find that simplicity's most vocal advocates often go off the deep-end, dismissing extremely productive technologies and practices simply because they appear complex when viewed from a certain angle. To use the author's own quote: > There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity. Nothing is a cure-all. That includes a relentless focus on simplicity. If your language is minimal, it probably means you're going to have a lot more complexity in the code itself. Maybe that's worth it, maybe it's not. There's also no hard line between accidental and intrinsic complexity; the goal-posts shift when things get generalized at the language or library or service level. Both the complexity of the holistic system, and the complexity of what you and your team actually need (or don't need) to manage yourselves, have to be considered. In short, the landscape is more complex (no pun intended) than the ideology represented here.
mwcampbell 5y ago
> There is less magic, less hiding, which yields much, much greater clarity. No surprises, ‘it just works’. I think the author of the following article would disagree: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
kinjba11 5y ago
Go values stability. But time passes and big changes do happen. Go modules. Generics. I wonder how many of the same arguments were made about Java back in the day. Java got generics at around 8 years after its 1.0 release in 1996. Go's getting them 9 years after its 1.0 release in 2012. We should probably compare apples-to-apples. C++ has been around for 35+ years. Java has been around for 25 years since its 1.0 in 1996. Python for 26 years. C# for 20 years. I wonder what people will think of Go in 10-20 years when its age matches more established ecosystems. Will devs be complaining about dealing with pre-generics code then?

258 points by kiyanwang 5y ago

Nitpick: "[The System/360] was the worlds first real programmable mainframe computer, opening up the notion that computers could be reprogrammed to suit new problems instead of being replaced by newer models." The S/360 was by no means the first programmable computer. Rather, it was the first computer product line where all systems were compatible with each other, and where future models would all retain backwards compatibility. The selling point was that you would not have to rewrite your code (or make significant changes) if you wanted to move to a larger system.

Koshkin 5y ago
That’s some nit that you picked! What else might be there, I wonder now.

johndoe0815 5y ago

Software complexity also helps to establish or maintain the predominance of large corporations on the market. In contrast, a simple software system can be reimplemented by a small team or even a single person, so there is more competition. This is not only demonstrated by Wirth's systems, but also by several 7th edition Unix clones of the 80's [1-4] as well as current ones [5] and also reimplementations of the classic MacOS [6]. Back in the 1980s, operating systems and compilers were often seen as the most complex pieces of software. Nowadays, web browsers include (and reimplement) large parts of an OS and compiler and are probably even more complex than a current OS such as Linux or a current compiler such as clang/LLVM. Only rich (or well funded) companies such as Google, Apple and the Mozilla foundation can afford to build a browser today that can be used to access current web pages. So a central question is if we can turn back times and make software more simple again. Maybe this ship has already sailed - but it can't hurt to try. From experience with my students, it is extremely satisfying for them to build a complete system from scratch instead of mostly copying and pasting library calls or StackOverflow code snippets. Thus, I try to enable my students to experience this sense of achievement. They will probably never get the chance to do something similar in their later career in industry. [1] One Man Unix for 68k - http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html http://www.pix.net/mirrored/discordia.org.uk/~steve/omu.html [2] Uzix for Z80 (link to the MSX port) - http://uzix.sourceforge.net http://uzix.sourceforge.net [3] Coherent Unix - https://en.wikipedia.org/wiki/Coherent_(operating_system) https://en.wikipedia.org/wiki/Coherent_(operating_system) [4] Minix - https://www.minix3.org https://www.minix3.org [5] Alan Cox' Fuzix - https://github.com/EtchedPixels/FUZIX https://github.com/EtchedPixels/FUZIX [6] Ardi Executor - https://en.wikipedia.org/wiki/Executor_(software) https://en.wikipedia.org/wiki/Executor_(software)

dmitriid 5y ago

Too many leaps of faith and too many appeals to authority. Wirth's quest for one true small language led to an array of languages that only show that no, you can't have too simple of a language, or you will end up with a system that is too complex because of the language. The ones I remember from a very long discussion a decade or so ago: - the meaningless distinctions between functions and procedures - the very many iterations on loop constructs (in some of his languages there are three loop constructs with different rules. For example, you can break early from only one of them) IIRC in Oberon BlackBox the necessity for complexity is just swept under the rug where system modules are allowed operations that are not available to user modules (IIRC it was function overloading and exceptions? I could be wrong). In many ways Go is following Wirth's path of confusing language complexity, problem complexity and solution complexity. Yes, you can a wonderfully simple language with very few constructs. But if you have to write thousands of lines of boilerplate code to handle a problem, you haven't solved complexity. You've offloaded it onto the programmer. As for "OMG, Wirth wrote an OS in Oberon, he was onto something"... Menuet OS is written in assembly, fits on a floppy disk, and can boot near-instantly on a 200 Mhz processor [1]. Does this mean we should ditch all the bad complex languages and switch to assembly? Though I agree: most of present-day software is extremely bloated and inefficient. [1] https://en.wikipedia.org/wiki/MenuetOS https://en.wikipedia.org/wiki/MenuetOS

zetalyrae 5y ago
>Wirth's quest for one true small language led to an array of languages that only show that no, you can't have too simple of a language, or you will end up with a system that is too complex because of the language. The ones I remember from a very long discussion a decade or so ago: >- the meaningless distinctions between functions and procedures >- the very many iterations on loop constructs (in some of his languages there are three loop constructs with different rules. For example, you can break early from only one of them) Arguably the problem here is Wirth didn't go far enough. You can design a simpler version of, say, Modula-3 by unifying statements and expression as in ML, and replacing the multiple iteration constructs with recursion, and guaranteeing tail recursion.
- masklinn 5y ago

arkj 5y ago

>> You have to completely comprehend your idea in order to fully realize it. This is a gem.

emmanueloga_ 5y ago
Corollary: you will fully comprehend your idea once you have fully realized it :-). My point is that iterative implementation often helps to better understand the problem, I think.
vidarh 5y ago
Indeed. Wirth's insistence on only adding those things to his language he fully understood was one of the things that inspired me to start writing a Ruby compiler (long dormant in an "almost self-compiling but wildly incomplete" state; I tinker with it every now and again but haven't had time since May judging by my last notes) - it struck me that fully understanding the true complexity of Ruby as a language required understanding how to implement it efficiently. I love using Ruby, but it's an absolute nightmare of a language to implement (and far worse to compile), and it's if anything driven home an appreciation for Wirth's insistence on simplicity.
Koshkin 5y ago
The word “realize” has two meanings, one is “understand” and the other (perhaps less used), “make real” or “implement.” (I would still disagree with the sentiment - better understanding often comes during implementation.)

erik_seaberg 5y ago

> You cannot reduce the complexity of your problem by increasing the complexity of your language. This strikes me as backwards. There’s a certain amount of irreducible complexity in any requirements, and every commonplace problem the language refuses to solve is one more problem for me to face with no help. Nearly every feature that makes a language more concise and powerful (reentrant functions, higher-order functions, tail recursion, continuations, dynamic dispatch, multiple dispatch, garbage collection, sum and product types, pattern matching, exceptions, concurrency, laziness, macros) makes it harder to specify and implement, but reusing a heavily tested implementation that everyone knows is always better than trying to roll my own. > Language is (comparatively) easy to pick up. This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. It’s like boasting that your toolbox is easy to carry, because it’s empty. > Deploy by running a single executable. This is not a good thing. It guarantees you can’t reuse any code provided by the platform. Static linking was a problem that was solved in the 1980s, and being able to choose it is always better than being forced into it. Anyway, Go does have a GCC-based toolchain with a normal linker, even if proponents prefer the one that reinvents everything incompatibly. > Being stuck in the 70s means no breaking changes since flared pants. I actually agree that languages should commit to “if you ask for the 2021 semantics that’s exactly what you get now and forever,” but any language can do that, we don’t have to settle for weak ones.

zetalyrae 5y ago
>This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work. I disagree with this. There are many languages that are perfectly productive which are reducible to a very small core: Haskell, Standard ML, OCaml, Modula-2/3. The size of the ecosystem is an extrinsic property to the language. Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. Very rarely does language complexity buy you anything except painful surprises or obfuscated code contest entries. For example: Rust is a much simpler language than C++ and you can use it to do essentially anything reasonable you'd want to do in C++.
- 5y ago

lifthrasiir 5y ago

This article wants to portray Go as a "small" language, but the batteries-included standard library is definitely a part of the language and Go is nothing but a small language by this measure. It is not hard to have just a large standard library (see Python), but a coherent one is difficult and requires a ton of efforts---with a large corporate backing in this case. By having a large and coherent standard library Go effectively swept the complexity under the carpet. Which is fine while it lasts.

jstx1 5y ago
> By having a large and coherent standard library Go effectively swept the complexity under the carpet. Which is fine while it lasts. Are you implying that it's a bad thing? Complex things that are frequently used got abstracted away so they can be easily reused - sounds great to me. Why wouldn't it last?
- lifthrasiir 5y ago
  It is not necessarily bad, but a language with a large standard library isn't small. The article prominently features the benefit of small languages, which (I only agree partly but notwithstanding) wouldn't apply to a language with a large standard library no matter the size of the core language. Therefore the article's final claim is invalid, no matter it actually turns out to be true or not.
solaxun 5y ago
I'm not sure how the size of a standard library has any bearing on the size and perceived complexity of the language. To me, it's about how many language features/keywords/constructs etc. one must keep in their head to effectively write code, including writing the standard library. I'd rather have a language with a very small core and an extensive set of libraries implemented with that core than one with a large core that tries to handle everything with features. There's something to be said about comprehensibility of libraries written in a language with a small and focused core, as well.
- 5y ago

nickd2001 5y ago

Perhaps someone will answer this related Q.. Having coded in Python for years, I'm underwhelmed by claims of Go's simplicity. Python, with its batteries included, seems to me simpler to code in and for understanding existing code, and easier to produce more maintainable code in as far as I can see. (this may partly reflect my prior experience to be fair) When I looked at Go, it looks like one has to do acrobatics and write a load of code to get around missing basic libraries and features in the language. So, I can see Go is useful for being very lightweight, and a good replacement for C++ for many things, but as for it being simple.... well, really? I guess does "simple" mean, relative to the likes of C++ ?

emmanueloga_ 5y ago
There's a talk called "Simple made Easy" by Rich Hickey (you can find it in YouTube) that talks about the difference between simple and easy in software development. Under those definitions, I agree some things in Go are not necessarily as easy to solve as in Python, but Go is definitely simpler.
- tharne 5y ago
  That talk should be at the top of every programmer's list. At the risk of sounding cliché, it actually will change how you think about program design.
  - Calamitous 5y ago
    Most of Rich Hickey's talks fall into that category.
- Scarbutt 5y ago
  You have it backwards, Go gives you the illusion that is easy (easy to start with, quick to start coding something in it) but is no simple. Writing simple systems is hard and Go works against you here.
luxurytent 5y ago
There's a few notes in the article that touch on why Go is simple. FWIW, Go comes with plenty of batteries included and as a day-time Go developer, most of what we build doesn't require external libraries (generally logging, database modules, etc. are external) Also what makes Go simple? This (From the article): > If it worked ten years ago, it works now. I have a collection of blog posts from the Go blog and other sources which I revisit from time to time and many are from indeed, ten years ago. Less cognitive overhead on figuring out what's from version x or y, if it's been deprecated, etc.

dgb23 5y ago

I really like Go and respect the authors and maintainers of the language. It is well designed and achieves its goals exceptionally well. The author of this article is right: Give it a Go! You'll learn it quickly and will appreciate having learned it, there are many, very considerate design decisions to discover, ranging from language implementation, tooling and the standard library. I'm sometimes jealous of Go's users, the language is very readable, light and refreshingly straight forward. That said, I cannot bring myself to use it (anymore). The language doesn't scale with my ability and in some sense seems almost patronizing. I'm not a particularly good programmer, but I'm experienced enough that I feel held back by languages like Go. When you are used to more power, expressiveness and clarity, then you just miss it at every step of the way. On one hand the language doesn't let me encode higher level thinking directly (relational, functional, domain specific...) but I have to act as a compiler. And vice versa it doesn't expose the low level control that one would want to squeeze out performance and minimize resource usage either. Again, Go still feels attractive in some sense, and I wish I had a reason to use it more, but I can't find it.

t8sr 5y ago
I think not letting you encode relational, functional and domain-specific higher level thinking is by design. I review a lot of code, and have been programming for 20 years. I think most programmers go through a phase, after 2-5 years of experience, where they get really into higher-level thinking. Everything is written according to a mantra like TTD, functional design, or everything-is-an-object, and they spend most of their complexity budget on abstractions. The code people write in that stage of their careers looks to them like an improvement over the simpler concepts they started with, it ends up being so much technical debt 12 months later, because almost nobody is good at predicting which higher-level concepts you are going to need, and by the time you realize you were wrong, it’s too expensive to remove them. It’s hard for a language to encourage this kind of you-ain’t-gonna-need-it thinking without seeming patronizing, but I promise you that the next 10 years of your career will change your mind. (I realize I also sound patronizing and I’m sorry: I typed this on a phone, so left out some caveats, such as I don’t know you and your background.)
- 5y ago

mongol 5y ago

> Even cellphones are powerful enough to calculate every computation humanity had computed by the 20th century put together. What does he mean? A single cellphone? Or all cellphones in the world combined?

carnitine 5y ago
A single cellphone.

smikhanov 5y ago

> Now, perhaps OSX is more feature complete than Oberon, > but certainly not by a factor of ~40 000X. Not sure why the author is so certain of that. Isn't that conceivable that a modern industrial-grade OS is 40 000 times more feature rich compared to its academic counterpart from 35 years ago?

geodel 5y ago
No, it is not conceivable to me as user. Though it could be for product managers creating release notes every month from thousands of GitHub issues or JIRA tickets resolved and listing features.

eesmith 5y ago

> "it has taken more than two weeks for the result to come back" That sounds exceptionally long for that era. I didn't easily find hard numbers. https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newland-J-1981-PhD-Thesis.pdf https://spiral.imperial.ac.uk/bitstream/10044/1/35672/2/Newl... (in a student environment in 1981) shows a turn-around from 20 minutes to 6 hours. See page 123 table 4.1. Also in a student environment, early 1970s, https://ir.library.oregonstate.edu/downloads/8g84mp855 https://ir.library.oregonstate.edu/downloads/8g84mp855 "Batch turnaround time averages somewhat less than a hour with a range of one-half to three hours." At The Rand Corporation in 1974, "Normal batch turnaround for jobs run during the day had averaged 30 minutes for quite some time." - https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 https://dl.acm.org/doi/pdf/10.1145/1500175.1500305 More generically, "Turnaround time may take minutes, hours, days or even more than a week before completed outputs are returned in response to job requests." - https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 . Two weeks therefore sounds very much like an outlier. > "Meanwhile, another engineer programming in Smalltalk and Interlisp is writing and running their implementation directly against a system console." Or BASIC, developed in in 1964 along side with the Dartmouth Time Sharing System. For example, by 1975, the HP 2000F was "the first minicomputer to offer time-shared BASIC", and it supported Fortran and other languages besides BASIC. https://en.wikipedia.org/wiki/HP_2100#HP_2000 https://en.wikipedia.org/wiki/HP_2100#HP_2000 Python is the modern BASIC. Also, note that interactively starting a long job (eg, compiling a large FORTRAN program) only saves the manual batch submission overhead. The compilation might still take time to run, especially if it requires system resources that aren't currently available so is still put into a queue. > Forget about a “10X programmer”, how about a “10 000X programmer”? That is not supported by the research. See https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 https://dl.acm.org/doi/pdf/10.1145/1468075.1468077 for one summary of several papers comparing batch vs. online computing. The Grant-Sackman paper is the only of those using professional programmers instead of students. The summary is "Time-sharing requires fewer man-hours to debug programs for highly experienced programers than a simulated batch system with a two-hour turnaround time." (19.3 hours instead of 31.2) and "Individual performance differences in 3 highly experienced group of programers are considerably larger than observed system differences between time-sharing and batch processing"

5y ago

lazyjones 5y ago

Unfortunately, large parts of the IT industry thrive on excess complexity in software and languages. Which is probably why Wirth's languages went out of fashion at some point in the early 1990's. As far as Go is concerned, it really started out well, but with generics it finally broke ties with Wirth's spirit because adding them to the language makes it unnecessarily bloated and will never reduce the complexity of your problems.

zija 5y ago

From top popular language, say from https://redmonk.com/sogrady/2021/08/05/language-rankings-6-21/ https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2..., only Go and Swift/ Objective-C are languages with static typing, compiled to native tool chain . And Swift are very apple centric. This have huge impact for go popularity. Alternative to Go: - java and JVM language are heavy gorilla languages that's need more resources/ no value types. graal native is not straightforward alternative. - C# is good alternative, but again jitted, and there are no alternative for Microsoft products in open source community,people choose go as default alternative to java few years ago..

Zababa 5y ago
Did you forget about C++ and Rust?
- zija 5y ago
  No, i like Rust very much. But Rust require from me to deep dive with language, it's not productive language, it's correct from start to end language. Language with optional GC, value types like Nim or D are better for small hobby projects. But community and library ecosystem and tooling are weak. On other hand there are Ocaml and F#. But Ocaml for windows is weak, community is small etc F# inherits problems from c#
  - Zababa 5y ago
    That's a fair point, but I don't find Rust really harder to use than Go for small hobby projects. Swift is nice as a language but has a huge lack of libraries.
  - AnimalMuppet 5y ago
    OK, but this: > From top popular language, say from https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2 https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2..., only Go and Swift/ Objective-C are languages with static typing, compiled to native tool chain is still false.
5y ago

mongol 5y ago

Would be interesting to compare the success of languages, by comparing those that were born in academia vs born in industry. For example, Python I believe can be said to be born in academia, while Java in industry. Obviously, industry-born languages still borrow from academia, but what have been the extra ingredients that made them more successful (=more used) than "obscure" languages that remained in academia?

pjmlp 5y ago

> Having created PASCAL, MODULA and MODULA-2, Wirth set out to develop the OBERON family of languages in order to build his operating system on his workstation. This is not quite true. Modula and Modula-2 originated from Wirth's first sabattical at Xerox PARC, where he got acquaited with Mesa and the XDE development environment, back at ETHZ he created Modula/-2 and the Lillith OS. On his second sabattical at Xerox PARC, Mesa had evolved into Mesa/Cedar, and that was the genesis for Oberon, his second workstation OS. Also although I appreciate Wirth's work, for me the best languages were Modula-2, and Active Oberon, while the best Pascal dialect is indeed what Apple and Borland did with it. I am not a fan of Wirth's later pursue for the minimalist GC systems language design.

fredrikholm 5y ago

Author here. This thread made my day. To the people who have commented, thank you. I seldom get to interact with SE people who enjoy their craft, and to see that so many have not only read my post but spent time writing out (dis)agreements brings a smile to my face. Some people have pointed out some historical inaccuracies, to which I'm grateful. Most of these points are taken from random sources I've consumed over the years, including for instance the two-week-turnaround, which was a hand-wavy quote from Brooks (video interview) for which I don't remember the source. Using it was for effect, perhaps a bit too eager on my part. I'm new to writing, and by extension, putting my thoughts to paper. This blog entry was written to concretize my thoughts on this subject, as I've found that writing them down helps to clarify them a lot, and to practice my English (non-native speaker). On the subject of minimalism: I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today, and what was standard then is outdated (or even deprecated) now. Throw in some IDEs, frameworks, licenses etc. and the amount of man-hours lost to auxiliary ad-hoc work has been both draining and expensive (for our customers). Switching several projects to Go mitigated this almost immediately, where the return of investment combined with the novelty factor has lifted the spirits of not only me but the people I've worked with. Going back is (for me) out of the question, at least for the time being. Happy to see people sharing their thoughts on this. Cheers :)

dmitriid 5y ago
> I've spent a few years in C#, Java, Swift, C++, JavaScript and Haskell. In all of them, the passing of time has always been a problem. What worked two years ago is broken today Java, C# and Javascript are obsessive about backwards compatibility (one of the reasons Java's changes to the language are moving so slow). There's nothing magical about Wirth's languages or Go. What worked two years ago will be broken today, and the language has very little to do with it. > Switching several projects to Go mitigated this almost immediately As in: you haven't run into things that are broken yet.
- fredrikholm 5y ago
  > Java, C# and Javascript are obsessive about backwards compatibility This might be true for Java, but this has not been my experience for the other two. NET especially. Incrementally migrating from 4.6.* to CORE3 has been challenging, even when we've had external (expert) .NET consultants to help us. > There's nothing magical about Wirth's languages or Go. I don't think so either! On the contrary, they're everything but magical. > What worked two years ago will be broken today, and the language has very little to do with it. Almost on the dot two years since those rewrites happened and nothing (to my knowledge) has broken. On the contrary, looking at code examples and best practices from 2011 look exactly the same. Writing Swift, anything older than 2019 made me sweat. > As in: you haven't run into things that are broken yet. Longest record so far! :)

Simplicitas 5y ago

You had me at "Deploy by running a single executable"

candyman 5y ago

After a few decades away from programming I got back into it some and decided that Python was the easiest and closest to the languages I was fairly fluent in back in the old days. I did write a lot of Pascal code at one point and after going through the "give it a Go" link I can see the appeal. It looks like a good tool for some things. I look forward to working with it some more. Thanks for your article. I have always enjoyed Brooks and Wirth so that's some good "geek clickbait" that I can't resist!

jksmith 5y ago

It's unfortunate that few here will have used M2 in a commercial setting. Well crafted M2 code led to feelings of deep satisfaction. It was like codification of quality.

zepto 5y ago

I love the piece in general, but one statement stands out to me: > Now, perhaps OSX is more feature complete than Oberon, but certainly not by a factor of ~40 000X. I am not at all sure that this is true. Unix alone has a vast feature set. Then consider just the features connected with something like displaying type, or accessibility. OS X is complex because it has accreted a large collection of messy human requirements. > Something was lost along the way. This is 100% true. Even to me, as someone who thinks Apple does good work, OSX doesn’t feel like a general purpose computer in the way that someone like Oberon or an Alto running smalltalk does. The Kay quote comes to mind: “ Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.” It a bit unfair to Apple. There is structural integrity to OSX, but it’s like a civil engineering project where the integrity is gradually being retrofitted over time.

scroot 5y ago
> There is structural integrity to OSX, but it’s like a civil engineering project where the integrity is gradually being retrofitted over time. Despite the engineered "user-friendliness" of the OS, it still suffers from a simple problem, which is this: how can a user make a button for themselves? There are buttons all over the system. Users know how to interact with them. But the only consistently supported way to make a "real" button is to learn a full low-level language and all the dev tools and classes that go with it. That is not good design.
- zepto 5y ago
  I agree with the sentiment, and indeed I’ve been disappointed with the rate of progress in this area by Apple, however they clearly are slowly moving in that direction. But to me the question this raises is - do you think anyone has done better, and if so who?
  - scroot 5y ago
    > But to me the question this raises is - do you think anyone has done better, and if so who?. Yes. Apple in the past, for one. When they included Hypercard free with every Macintosh and also began integrating Applescript into the core of their OS, they were taking steps in the right direction. Also, as you mentioned, Smalltalk and similar systems also had a good trajectory in this regard. The incentives and visions of computing have changed drastically since the 80s.

chauhankiran 5y ago

I want to know what author or others think about Elixir? I recently started learning and found it interesting and something totally new than what I know.

fredrikholm 5y ago
OP links to my previous entry, 'Why Erlang'[0] near the end! :) 0. https://www.fredrikholmqvist.com/posts/why-erlang/ https://www.fredrikholmqvist.com/posts/why-erlang/

rramadass 5y ago

The main premise of the article seems to be; 'You cannot reduce the complexity of your problem by increasing the complexity of your language.' Disagree; eg. DSLs. Here "Simplicity" is born out of a large array of "Complicated Constructs" in some language. The size of the surface area encompassing the various constructs is directly proportional to the expression of various possible models of computations and thus effective problem solving. This idea is what is behind the Mozart/Oz language (and of course C++ :-)

d0100 5y ago
> 'one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.' I think this is also a premise of the article, I don't see that quote as "the main" premise, but just another quote used to explore the overall points presented
- rramadass 5y ago
  The article is trying to focus on "Simplicity"(in everything?) with Go being the exemplar according to the author. However it confuses two major issues; Simplicity in the Language used for expression vs. Simplicity in the Solution of a Problem. They are two very different things; and the quote you list (by Tony Hoare) actually refers to the latter. Simplicity in the solution of a problem is not to be argued against. This was the main thrust of Wirth's work (see also the book The School of Niklaus Wirth: The Art of Simplicity). But he presupposed that this is only possible by using a "Simple" language. This is what is debatable. I think with the experience that the community has gained now (in terms of volume of software written) we are realizing the need for "Complex" languages/libraries/frameworks.

abeyer 5y ago

> If it worked ten years ago, it works now. As long as it isn't a dependency management system. /s

brundolf 5y ago

I'm a big advocate for simplicity. I think it's one of the most important guiding principles in software engineering. I don't care for Go mostly for reasons unrelated to its simplicity; I have respect for the latter, even for decisions like excluding generics. I think broadly that we need more simplicity-focused languages. However, I find that simplicity's most vocal advocates often go off the deep-end, dismissing extremely productive technologies and practices simply because they appear complex when viewed from a certain angle. To use the author's own quote: > There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity. Nothing is a cure-all. That includes a relentless focus on simplicity. If your language is minimal, it probably means you're going to have a lot more complexity in the code itself. Maybe that's worth it, maybe it's not. There's also no hard line between accidental and intrinsic complexity; the goal-posts shift when things get generalized at the language or library or service level. Both the complexity of the holistic system, and the complexity of what you and your team actually need (or don't need) to manage yourselves, have to be considered. In short, the landscape is more complex (no pun intended) than the ideology represented here.

mwcampbell 5y ago

> There is less magic, less hiding, which yields much, much greater clarity. No surprises, ‘it just works’. I think the author of the following article would disagree: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

kinjba11 5y ago

Go values stability. But time passes and big changes do happen. Go modules. Generics. I wonder how many of the same arguments were made about Java back in the day. Java got generics at around 8 years after its 1.0 release in 1996. Go's getting them 9 years after its 1.0 release in 2012. We should probably compare apples-to-apples. C++ has been around for 35+ years. Java has been around for 25 years since its 1.0 in 1996. Python for 26 years. C# for 20 years. I wonder what people will think of Go in 10-20 years when its age matches more established ecosystems. Will devs be complaining about dealing with pre-generics code then?