I really hope it keeps gaining momentum.
This was reason enough for C to get popular.
Only if commercial UNIX and Windows also get rewritten in Go.
> This was reason enough for C to get popular.
C got popular because UNIX was adopted by the enterprise and C was the system language.
I doubt C would ever been popular without UNIX.
Mhm.
> ... easy to reason about...
So very much no. There is nothing about the stateful nature of C-programming, its syntax or the patterns people use that is easy to reason about. You're comparing it to what, exactly? C++? C is an amazing language but comparing it to the languages that were around when it became popular it's not even close to relatively easy to reason about. Even less so nowadays.
> provides enough abstraction to easily write complicated code
This strikes me as a weird thing to list in "pros". Complicated is the opposite of good. Abstractions should let you write simple code, not complicated code. I feel like you've either misunderstood the word "complicated", massively mischaracterized C or you have a very weird view on abstraction.
> Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.
I'd like to point out that your assumption that people use programming languages because they are better than the alternatives is pretty naive. The most popular languages are decent, no doubt, but have you noticed how every really good language suffers from a pretty huge lack of users? We all know these languages are better, but it's never been an issue of "You're not good enough for people to use you".
If there was ever any indicator for a good language it'd be "What do people choose when they have the freedom, knowledge and opportunity to choose anything without any outside influence?". That scenario is so wildly scarce to observe and anyone who is in that situation likely suffers from biases acquired earlier on his programming journey.
>What was taking its place at that time?
Pascal was fairly heavily used, but was dying out. LISP was hot because it was the middle of the Great AI Boom, Modula-2 was supposed to replace Pascal and be a systems programming language, and ADA was supposed to be the next great thing. Apple had created Object Pascal. Self was the big research language. Nothing really took hold until C++ in the latter part of the 1980s.
The UK financial sector seem to like academic stuff then.
For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.
Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.
So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?
Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."
Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?
This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?
EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.
[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-St...
I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
The current grandaddy is Devel::REPL - https://metacpan.org/release/Devel-REPL
The new kid on the block is Reply - https://metacpan.org/release/Reply
PS. I do find using a Perl REPL invaluable for me.
Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself.
I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.
No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages.
> there's no dynamic typing
Yes, there is, through `interface{}`.
You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).
There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal.
Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.
In Ruby it's as easy as:
require 'ruby-debug'; debugger
import pdb; pdb.set_trace()
It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
[1] http://msdn.microsoft.com/en-us/library/f177hahy(v=vs.71).as...
[2] http://msdn.microsoft.com/en-us/library/aa716276(v=vs.60).as...
The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
So what?! Languages and implementations are not the same thing.
So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?
Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).
Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.
> though Smalltalk developers are probably laughing at me right now
Yes we are. :)
Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.
Sadly, Lisp machines and Smalltalk environments died on the mainstream.
For java there is bean shell/groovysh which isn't quite as good.
There is a mono repl and there is linqpad for c#. Ive used linqpad and it is very usefull.
scala worksheets are also very cool.
This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.
C# ==> http://www.mono-project.com/CsharpRepl
C++ ==> http://root.cern.ch/drupal/content/cint
C ==> http://www.softintegration.com/demos/chstandard/interactiveC...
Java ==> http://www.javarepl.com/console.html
People, please pay attention in compiler design classes and don't mix languages with implementations.
I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.
I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.
If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.
A REPL is a nice learning tool, but actually not that useful for productive programming. Go has a playground for learning and experimenting.
I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use).
There are other REPL-like tools like [2] and [3].
[1] https://github.com/shurcooL/Conception#demonstration