[HN Gopher] Designing a Programming Language (2015)
___________________________________________________________________
Designing a Programming Language (2015)
Author : tmfi
Score : 74 points
Date : 2021-03-27 11:03 UTC (11 hours ago)
(HTM) web link (ducklang.org)
(TXT) w3m dump (ducklang.org)
| merricksb wrote:
| Original discussion in 2015, for those curious:
|
| https://news.ycombinator.com/item?id=9901282
| awb wrote:
| I hope that at some point language design will become a self-
| contained discipline.
|
| It reminds me of back in the early days of the Internet when
| developers were the only web designers. Most programming
| languages are designed by the same people implementing them.
|
| The common critique is that language designers might create a
| syntax incompatible with the limitations of the computer itself,
| but that's the same challenge web designers had to learn in
| designing something that will look great in the constraints of
| the browser, and not just look good in Photoshop.
| jhardy54 wrote:
| Programming language theory is its own branch of computer
| science, but I'm not sure whether that qualifies as a "self-
| contained discipline":
| https://en.wikipedia.org/wiki/Programming_language_theory
|
| Or, do you mean that linguists might design programming
| languages without ever having learned how to program?
| seanmcdirmid wrote:
| Programming language theory is a hugely different field from
| programming language design. One is a theory (lots of math
| and proofs), the other is much more similar to being a UX
| designer (a lot of usability issues to work out where theory
| doesn't help). It gets confusing because many PL designers
| are also PL theorists, but it isn't true in every case.
| awb wrote:
| > Or, do you mean that linguists might design programming
| languages without ever having learned how to program?
|
| Yes
| kazinator wrote:
| Human disciplines are generally organized around something that
| generates a high volume of repeating work. E.g. we have civil
| engineering as as discipline because bridges have to be
| designed (or existing designs have to be adjusted and
| instantiated to new situations). Such a discipline is practiced
| everywhere; every populated region in the world has civil
| engineers cranking out work.
|
| We don't need similar discipline which cranks out programming
| languages.
|
| To some measure, we need programming languages in which regular
| programmers can crank out domain specific notations to suit
| whatever work they are doing.
|
| Engineers themselves use languages for designing and
| communicating their work. Civil engineers have blueprints with
| their notations; electrical engineers have schematics, SPICE
| netlists; and so on. They don't need a sub-discipline to
| continuously crank out new kinds of these languages, right?
|
| Similarly software engineering has languages. It has a lot more
| of them than electrical or civil engineering, but that's just
| the consequence of those languages not only being the product
| of software engineering as well as the production tool.
|
| Non-software engineering also produces tools which are used in
| engineering. We have a myriad of tools for all sorts of
| situations. Machinists produce tools, which can be used by
| machinists to produce tools; that's a bit like computing.
|
| In computing, there are tools other than languages though. For
| instance, there are API's and libraries. There is still a lot
| of work, for instance, in people who integrate platforms: bring
| up new systems on a chip, and move code to next generation
| systems.
|
| New API's are needed much more than new languages, and so the
| case can be made that API's are more like tools than languages.
| Machinists generally don't need a new design language in order
| to make new tools. A new tool is an adapter between a process
| (like construction, maintenance) and a new situation; it's like
| a HAL. A differenty shaped screwdriver or whatever isn't a new
| language.
| AnimalMuppet wrote:
| > electrical engineers have schematics, SPICE netlists; and
| so on.
|
| How much "and so on", though? Schematics. SPICE. VHDL.
| Verilog. That's all I can think of off the top of my head,
| but I'm not an electrical engineer. There might be a few more
| - especially for subspecialties like, say, power engineers.
|
| How many languages do software engineers commonly use? Maybe
| ten. (I will admit that the word "commonly" is doing a lot of
| work for me...)
|
| And you could look at something like TypeScript as being a
| new API on JavaScript.
|
| So I'm not sure that we're that far out of line with
| something like electrical engineering. We just have a really
| long tail of languages that relatively few people use. To me,
| it feels like those "don't count" in a way, but you could
| regard it as cheating to ignore them.
|
| Note well: I am not at all saying that the languages we have
| are optimal for programming. I'm just saying that as a
| discipline, we mostly use a very few languages.
| kazinator wrote:
| Right, no much "so on and on", and note that those EE
| languages we mention are actually computing tools.
|
| Another consideration I should have mentioned is
| compensation. Civil engineers get paid for instantiating a
| new bridge somewhere.
|
| There is no money in cranking out programming languages.
|
| It takes years of dedication to just make one good one.
| musicale wrote:
| > SPICE. VHDL. Verilog. That's all I can think of off the
| top of my head, but I'm not an electrical engineer
|
| There are dozens of hardware description languages. In
| addition to Verilog and VHDL I've encountered SystemC and
| Bluespec as well as a number of less popular and academic
| languages (Lola, Esterel, even JavaScript-based HDLs...)
| (I've also encountered various lower-level languages, for
| schematics, netlists, or VLSI layout.) Languages enabling
| formal specification and verification seem particularly hot
| at the moment.
|
| Matlab/Octave and Scipy/numpy are certainly big in EE for
| signal processing and other applications.
|
| Obviously C-like languages and Python are used in many EE
| applications, as are GPU languages like CUDA and OpenCL.
| neonological wrote:
| What's always missing from these is the type checker.
| xigency wrote:
| There are some interesting methods of doing type checking
| without type annotations by doing type inference. It might be
| worth writing about - it's basically a recursive process of
| identifying types by their context, either in assignment or
| function calling.
| enriquto wrote:
| In many reasonable languages there are no types (or,
| equivalently, there is a single type) thus it may be perfectly
| OK to not have a type checker.
| otabdeveloper4 wrote:
| You're just delegating the type checking to an ad-hoc
| runtime.
|
| It's always better to check types rigorously and as soon as
| possible.
| enriquto wrote:
| This is not what I meant. I mean a language such as core
| matlab/octave, where the only "type" to speak of is the
| multi-dimensional array of floats.
| BoiledCabbage wrote:
| Does matlab/octave prevent you from performing invalid
| operations on arrays of different/incompatible
| ranks/dimensions?
|
| If so, then it's doing runtime type checking.
| enriquto wrote:
| Good point. Yes, not all operations are defined, and it
| may result in a runtime error.
| [deleted]
| seanmcdirmid wrote:
| There are strongly (and weakly) dynamically typed languages.
| Harper's classification ignores that.
| IncRnd wrote:
| Yea. This page isn't about Designing a Programming Language. The
| page is about Implementing an Interpreter of a Programming
| Language without any actual design, just implementation.
| codr7 wrote:
| The most important advice in my mind would be to waste as little
| time as possible on the parser; Forth is trivial, Lisp a tiny bit
| more involved.
|
| https://github.com/codr7/liblgpp
| gjm11 wrote:
| If you care at all about getting people to _use_ your language
| (which you might not, as with Haskell's "Avoid popularity at
| all costs" slogan) then I don't think this is good advice.
|
| Both Forth and Lisp have seen less adoption than their
| aficionados think they deserve as a result of their offputting-
| to-muggles syntax.
|
| In both cases, arguably the most important merits of the
| language actually necessitate the unusual syntax. That might
| mean that Lisp and Forth couldn't have done better with more
| conventional syntax. If so, what that means isn't that you
| should after all give minimal attention to the parser; it's
| that in some cases a syntax that's very simply parseable might
| be a good one -- but, unless you get very lucky, you will only
| discover that by thinking deeply about your syntax rather than
| doing something minimal and hoping it ends up having subtle
| merits like those of Forth and Lisp.
___________________________________________________________________
(page generated 2021-03-27 23:01 UTC)