This is the primary reason I find programming in Common Lisp so enjoyable, as opposed to Rust (a probably superior language, but having to wait for 300 dependencies to compile / get linked is a far cry from compiling individual functions in a running Lisp image)
The lack of IDE support for better C++ build systems (e.g. Bazel) is a boat anchor on C++. I’m struggling right now to find a CMake replacement which supports both Visual Studio and CLion on Windows and Linux.
An example: The important part of a Lisp Machine and why people lionize them wasn’t that it was written in Lisp, but that the environment was wide-open and transparent.
This is a big part of the appeal of Emacs. Elisp is arguably an awful language, but the ability to jump into source code and debug just about any part of it is very useful.
Interesting that they use JavaScript as an example of a good dev environment. As someone who’s been working in web for over 8 years and did some C, Java, and C# before that, I find it frustrating. Comparing my experience building web apps with React, Ember, Angular, ExtJS, and more to Elm and it’s like living in 2 vastly different worlds. The former means that I often don’t know about bugs or general issues until I run my code in the browser. It feels like knitting a sweater in the dark and only knowing if it works by trying it on. Conversely, Elm gives me immediate feedback. I don’t think everyone should write Elm, but its programming environment is vastly better than all of the JS tooling I’ve tried. Apso better than most back end languages I know/use.
One of Go’s claims to fame and primary design goals is compilation speed.
Interesting that the author brings up go the language but then doesn’t discuss the tooling that so many others have praised, even though it seems like to would be the kind of innovation that the author is looking for.
Erlang, with its advanced, concurrent, message-passing runtime, offers a better way to build high availability, highly reliable systems.
This point also interests me, because I’ve never thought about a programming languages run time as part of the environment, but more as part of the programming language itself. Except for C, it’s pretty rare to have a language divorced of it’s runtime, so should it really be considered as environment rather than just part of the language?
Does the compile-time / run-time distinction make sense to have? Can we give better control to developers about when their code is executed during the software development and deployment process?
In one word, yes. This is still one of the easiest ways to amortize the cost of some optimizations before giving it to the end user.
Interesting that the author brings up go the language but then doesn’t discuss the tooling that so many others have praised, even though it seems like to would be the kind of innovation that the author is looking for.
Taking a step in this direction: I think go’s executable examples are really cool. As part of a function’s documentation, you can write a usage example and its expected output, and the example will be compiled and checked against the desired output as part of the package’s test suite.
So I actually wasn’t aware of this paradigm before, though it does explain why it’s so much easier to find example uses of Go methods in the docs. I have to wonder though, how does one then write examples for code with side effects? Otherwise, the example in boto for how to instantiate an EC2 server could get rather expensive
This point also interests me, because I’ve never thought about a programming languages run time as part of the environment, but more as part of the programming language itself.
I think it’s usually a mix of both; the runtime environment affects the language and vice versa. But they aren’t necessarily the same thing.
Take Kotlin, for example. Its design reflects the semantics of the JVM to some extent. But it’s no longer a JVM-only language; you can target the JVM, JavaScript, or compile to native code. So is the JVM runtime environment part of the Kotlin language when you can run Kotlin code on a Node runtime instead?
So, in true internet fashion, I’m going to agree and disagree :)
You do bring up a good point about polyglot back ends for languages. The JVM and the official Java runtime is not part of the language for this exact reason. However, Kotlin does make a significant amount of work to make it feel like we’re still in a Java-like environment, even when we’re int he Node VM or on a native machine. So while there Java runtime is not a part of it, there is “some” runtime imbued into how the language itself.
While I agree that it’s good to consider programming wholistically, not just in terms of individual tools, I always get itchy when people say things like:
While professional photo editors and video games can run in the browser, why are we still using a repl that prints lines in the terminal?
Professional photo editors and video games and the kinds of beautiful data visualisations you see in TED talks are excellent and make information easily accessible and explorable, but they take many hundreds of person-hours to create, so they’re often a bad investment unless you’re pretty sure they’re going to help hundreds, thousands, or millions of people. Often when I’m debugging a problem, I might try half a dozen visualisations before I find one that makes the problem apparent to me, and I just don’t have the time or the expertise to make a really slick GPU-accelerated tool.
Yes, terminal output is very primitive, and it’s almost impossible to do anything with any degree of polish, but it’s amazingly, laughably easy to approximate most things. Certainly easier than it would be even with an immediate-mode vector graphics API, never mind OpenGL or Vulkan or a HTML/CSS/JS stack.
One of the most exciting developments I’ve seen in this area in the recent past is Glamorous Toolkit (https://gtoolkit.com/) because it’s not just some academic prototype and much more flexible than a lot of what’s out there. It’s pretty sad to see some “state of the art” tooling when compared to this.
Here’s a nice introduction: https://www.youtube.com/watch?v=Pot9GnHFOVU
I’ve been spending some time writing Observable notebooks and the experience really feels like a paradigm shift. Observable gives literate programming, interactive live coding and social & collaboration feature all within one space. It really feels like the single major successful innovation in the field for a long time. The article could also mention Smalltalk, Self, HyperCard or even VisualBasic as environmental that pushed the envelope and went beyond the compiler.
Observable uses a data flow approach to automatically update the cells independently of their order, and the kernel runs directly in the browsers. You can also import any symbol from other notebooks, making them more like literate modules.
I do see what the author is getting at here. Becoming competent in a development environment I think has helped me more than learning any language. Over the last year I have become an Emacs user, and I feel like the easier it is to integrate a programming language into Emacs the more quickly I become productive in it. I don’t think it’s Emacs specific though. I had a coworker who loved Sublime and he was a great!
This is the primary reason I find programming in Common Lisp so enjoyable, as opposed to Rust (a probably superior language, but having to wait for 300 dependencies to compile / get linked is a far cry from compiling individual functions in a running Lisp image)
Ha! I’m currently coming at this from converting a small C++ project to Rust and I’m finding Cargo to be so much more enjoyable than CMake :)
The lack of IDE support for better C++ build systems (e.g. Bazel) is a boat anchor on C++. I’m struggling right now to find a CMake replacement which supports both Visual Studio and CLion on Windows and Linux.
An example: The important part of a Lisp Machine and why people lionize them wasn’t that it was written in Lisp, but that the environment was wide-open and transparent.
This is a big part of the appeal of Emacs. Elisp is arguably an awful language, but the ability to jump into source code and debug just about any part of it is very useful.
Interesting that they use JavaScript as an example of a good dev environment. As someone who’s been working in web for over 8 years and did some C, Java, and C# before that, I find it frustrating. Comparing my experience building web apps with React, Ember, Angular, ExtJS, and more to Elm and it’s like living in 2 vastly different worlds. The former means that I often don’t know about bugs or general issues until I run my code in the browser. It feels like knitting a sweater in the dark and only knowing if it works by trying it on. Conversely, Elm gives me immediate feedback. I don’t think everyone should write Elm, but its programming environment is vastly better than all of the JS tooling I’ve tried. Apso better than most back end languages I know/use.
Interesting that the author brings up go the language but then doesn’t discuss the tooling that so many others have praised, even though it seems like to would be the kind of innovation that the author is looking for.
This point also interests me, because I’ve never thought about a programming languages run time as part of the environment, but more as part of the programming language itself. Except for C, it’s pretty rare to have a language divorced of it’s runtime, so should it really be considered as environment rather than just part of the language?
In one word, yes. This is still one of the easiest ways to amortize the cost of some optimizations before giving it to the end user.
Taking a step in this direction: I think go’s executable examples are really cool. As part of a function’s documentation, you can write a usage example and its expected output, and the example will be compiled and checked against the desired output as part of the package’s test suite.
So I actually wasn’t aware of this paradigm before, though it does explain why it’s so much easier to find example uses of Go methods in the docs. I have to wonder though, how does one then write examples for code with side effects? Otherwise, the example in boto for how to instantiate an EC2 server could get rather expensive
I think it’s usually a mix of both; the runtime environment affects the language and vice versa. But they aren’t necessarily the same thing.
Take Kotlin, for example. Its design reflects the semantics of the JVM to some extent. But it’s no longer a JVM-only language; you can target the JVM, JavaScript, or compile to native code. So is the JVM runtime environment part of the Kotlin language when you can run Kotlin code on a Node runtime instead?
So, in true internet fashion, I’m going to agree and disagree :)
You do bring up a good point about polyglot back ends for languages. The JVM and the official Java runtime is not part of the language for this exact reason. However, Kotlin does make a significant amount of work to make it feel like we’re still in a Java-like environment, even when we’re int he Node VM or on a native machine. So while there Java runtime is not a part of it, there is “some” runtime imbued into how the language itself.
While I agree that it’s good to consider programming wholistically, not just in terms of individual tools, I always get itchy when people say things like:
Professional photo editors and video games and the kinds of beautiful data visualisations you see in TED talks are excellent and make information easily accessible and explorable, but they take many hundreds of person-hours to create, so they’re often a bad investment unless you’re pretty sure they’re going to help hundreds, thousands, or millions of people. Often when I’m debugging a problem, I might try half a dozen visualisations before I find one that makes the problem apparent to me, and I just don’t have the time or the expertise to make a really slick GPU-accelerated tool.
Yes, terminal output is very primitive, and it’s almost impossible to do anything with any degree of polish, but it’s amazingly, laughably easy to approximate most things. Certainly easier than it would be even with an immediate-mode vector graphics API, never mind OpenGL or Vulkan or a HTML/CSS/JS stack.
One of the most exciting developments I’ve seen in this area in the recent past is Glamorous Toolkit (https://gtoolkit.com/) because it’s not just some academic prototype and much more flexible than a lot of what’s out there. It’s pretty sad to see some “state of the art” tooling when compared to this. Here’s a nice introduction: https://www.youtube.com/watch?v=Pot9GnHFOVU
Switching to CLion for C++ definitely upped my refactoring game, …
I’ve been spending some time writing Observable notebooks and the experience really feels like a paradigm shift. Observable gives literate programming, interactive live coding and social & collaboration feature all within one space. It really feels like the single major successful innovation in the field for a long time. The article could also mention Smalltalk, Self, HyperCard or even VisualBasic as environmental that pushed the envelope and went beyond the compiler.
I’m curious, can you say anything about how Observable differs from running Jupyter notebooks?
The Observable folks wrote a bit on how they differ from their perspective.
Thanks, that’s helpful
Observable uses a data flow approach to automatically update the cells independently of their order, and the kernel runs directly in the browsers. You can also import any symbol from other notebooks, making them more like literate modules.
I do see what the author is getting at here. Becoming competent in a development environment I think has helped me more than learning any language. Over the last year I have become an Emacs user, and I feel like the easier it is to integrate a programming language into Emacs the more quickly I become productive in it. I don’t think it’s Emacs specific though. I had a coworker who loved Sublime and he was a great!
Made me think of Dynamicland
[Comment removed by author]