4 ms·

Just as we separate web design and development into different disciplines, we should consider splitting language design and development into different disciplin

by awb 6y ago

Just as we separate web design and development into different disciplines, we should consider splitting language design and development into different disciplines as well. The V language looks beautiful (like an improved version of Go). There's always the chance someone will design something that's too complicated to develop, but that's the same with web design.

Barrin92 6y ago
I don't think a total split is reasonable (in both examples given). Technical implementation and design inform each other because there's always a point where limitations, performance, or some other aspect becomes relevant, and where having knowledge of both domains is very useful. You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.
- awb 6y ago
  Yes, ideally in both the designer has some mid-level understanding of development and the developer has some mid-level understanding of design. Without that overlap, things can go off the rails.
hardwaregeek 6y ago
Except in web design you rarely create a design that is literally, provably impossible to make
- delian66 6y ago
  Can you be more specific about what is impossible to make?
  - hardwaregeek 6y ago
    Any decent language designer should know the Halting Problem and how that translates to static analysis (Rice's Theorem). But more than that, it's quite easy to design typechecking algorithms that exhibit combinatorial explosion. A naive language designer could promise fast compilation speeds and robust typechecking with inference, assuming that typechecking could be sped up with caches and a fast implementation language. However if the typechecking algorithm is O(n^3), no matter what, compilation speed will be slow.
    - delian66 6y ago
      I lived through the early 90s, when Borland's Turbo Pascal and later Delphi, compiled programs in a fraction of a second. It proved empirically, that compilation does not need to be slow, if the language is simple and carefully designed. Go is also a good example. Computers are now several orders of magnitude more powerful. We do NOT have to wait for compilation of simple programs in 2020. In my opinion, waiting is more of a symptom of the current obsession with optimization, and disregard for ergonomics, than a fundamental CS result that is set in stone. Compare for example compiling a program with gcc and tcc (without optimizations, so that they are on equal grounds, because tcc does not strive to do optimizations, but strives to be fast and tiny) . tcc is usually 4-5 times faster.

by awb 6y ago

Barrin92 6y ago

I don't think a total split is reasonable (in both examples given). Technical implementation and design inform each other because there's always a point where limitations, performance, or some other aspect becomes relevant, and where having knowledge of both domains is very useful. You can have a designer say, create a great UI but if they are not aware of the underlying limitations of the tech it can create a lot of headache. This may be even more relevant for language design and implementation. Ideally you have 'all-rounders' around for these issues.

awb 6y ago
Yes, ideally in both the designer has some mid-level understanding of development and the developer has some mid-level understanding of design. Without that overlap, things can go off the rails.

hardwaregeek 6y ago

Except in web design you rarely create a design that is literally, provably impossible to make

delian66 6y ago
Can you be more specific about what is impossible to make?
- hardwaregeek 6y ago
  Any decent language designer should know the Halting Problem and how that translates to static analysis (Rice's Theorem). But more than that, it's quite easy to design typechecking algorithms that exhibit combinatorial explosion. A naive language designer could promise fast compilation speeds and robust typechecking with inference, assuming that typechecking could be sped up with caches and a fast implementation language. However if the typechecking algorithm is O(n^3), no matter what, compilation speed will be slow.
  - delian66 6y ago
    I lived through the early 90s, when Borland's Turbo Pascal and later Delphi, compiled programs in a fraction of a second. It proved empirically, that compilation does not need to be slow, if the language is simple and carefully designed. Go is also a good example. Computers are now several orders of magnitude more powerful. We do NOT have to wait for compilation of simple programs in 2020. In my opinion, waiting is more of a symptom of the current obsession with optimization, and disregard for ergonomics, than a fundamental CS result that is set in stone. Compare for example compiling a program with gcc and tcc (without optimizations, so that they are on equal grounds, because tcc does not strive to do optimizations, but strives to be fast and tiny) . tcc is usually 4-5 times faster.