9 ms·

I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody a

I disagree with a few of your thoughts, but they're good thoughts! * Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again. * WYSIWYG web design (a la Dreamweaver) died off a little because the tools saw a web page as standing in isolation. We know however that isn't interesting on its own - it needs to be hooked up to back-end functionality. Who is producing static HTML alone these days? In the case of SPAs it needs API integration. In the case of traditional web app dev, it needs some inlining and hooks to form submission points and programatically generated links to other "pages". Making that easier is the hard part - seeing a web document as an artefact of an output from a running web application container. * Multi-threaded, event-driven, coroutine-type patterns are fine in Go, to my eye. What's making you think we can't mix this up with the right type of language and tooling support? * Is it that we can't code well for CPU counts > 100 or that the types of problems we're looking at right now that need that level of parallelism tend to be targeted towards GPUs or even ASICs? I think I'd need to see the kind of problems you're trying to solve, because I'm not sure high CPU counts are the right answer. * Talking to GPU-type engines is actually pretty simple, we will deal with it the same way we deal with CPU-type engines: abstraction through a compiler. Compilers over time will learn how to talk GPU optimally. GPU portability over the next 20 years will be a problem to solve as CPU/architecture portability was over the last 40.

pjmlp 9y ago
> WYSIWYG web design (a la Dreamweaver) died off .... Which is why what we actually need is a la Delphi
- mseri 9y ago
  Interesting. Can you elaborate more?
  - pjmlp 9y ago
    Imagine WebComponents finally becoming mature and having a programming environment for RAD on the Web, using toolbox with drop-in components for doing application development. There are already some attempts at it, for example https://anvil.works/ https://anvil.works/
- tluyben2 9y ago
  I have been thinking about that and there is an issue with it; Delphi (and VB) where written in a time when devs paid a lot for software tools. Besides some niches (embedded) that is not really the case anymore. You expect to pay a few $10 at most in total if that. And a lot of people (but that might be the HN/Reddit echo chamber) demand all to be OSS as well they work with. Making 'a modern Delphi' is a lot of work; years of it. And much of that time is not 'fun', it's hard work polishing little parts and having user test groups feedback on it and polishing it some more. The time that you could be Borland seems gone (unfortunately imho) and i'm not sure how you can make the kind of polished tool you are talking about in the current climate. Maybe someone else here has some different views though.
  - pjmlp 9y ago
    There are companies trying it though, https://anvil.works/ https://anvil.works/ https://www.outsystems.com/platform/ https://www.outsystems.com/platform/ JetBrains is probably a good example of a "Borland" like company. Outside HN/Reddit bubble that are plenty of companies that are willing to pay for software, the supermarket cashier doesn't take pull requests. Also, the back to native focus on mobile platforms, including Google having to integrate Android apps on ChromeOS, might make it less relevant, given that native IDEs do offer some Delphi like experience.
    - tluyben2 9y ago
      Outsystems and Jetbrains are these examples but on the other hand they are not; they are 'old'; they both exist since 2000 and at that time pushing into the market was a lot easier. I was more thinking of a company starting now, to which I'll check out Anvil.Works. There are more new companies working in the space, for sure, but they all miss the breadth that Borland had (they really had a lot of cash and developers on hand in those days). But yes, Outsystems (I worked with them and their product quite a lot in the past) could be considered a Delphi. But still not modern; it's rather painful building apps/sites with it that people seem to want. Jetbrains can be considered a Borland; I didn't think of that because I consider them more in the space of 'low level' programming tools (which, like you say, includes Delphi functionality, but a modern Delphi wouldn't be like the old Delphi; it would need a lot more innovation).
- ako 9y ago
  There's a healthy market of RAD/lowcode tools similar to Delphi these days. One example is Mendix: https://www.mendix.com/application-platform-as-a-service/ https://www.mendix.com/application-platform-as-a-service/ Full visual development, runs on a scala runtime, can be deployed (visually) on cloudfoundry, docker/kubernetes, etc.
  - pjmlp 9y ago
    Thanks for the heads up, one more for my list. :)
- boznz 9y ago
  Funnily enough I was looking at the title and just thinking in 25 years time I will still be programming in the same three languages C, Pascal/Delphi and SQL I learnt 25 years ago.
tluyben2 9y ago
> Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language Everybody is everybody who has used other languages intensively or is into programming languages or, the most negative parties against JS, people who are into formal methods. But 'everybody'; I get often downvoted to hell for being negative on JS on Reddit. And i'm not using a baseball bat; i'm subtle about it as I don't care for language wars. Use what you want, but please don't say it's the best thing to happen to humanity. But no; 'everybody' (as in headcount) thinks it is the best thing that happened to humanity and that other languages should die because you can write everything in JS anyway.
- PaulRobinson 9y ago
  I said 'almost everybody'. Even the most ardent JS fans I work with call it objectively bad.
  - aaron-lebo 9y ago
    What are their objective measures?
    - SiVal 9y ago
      I can think of one: the fraction of design decisions that the language's creator, standardizers, and serious developers wish they could change but can't.
  - lhnz 9y ago
    It's hard to be objective on this. A modern JavaScript engineer would point out that: - The community is very accepting of new engineers. - The ecosystem is huge and there are great solutions available to many problems. - It's easy to write consistent code while avoiding many problems with the language if you use `eslint`, `prettier` and `flowtype`. Tooling on the web is excellent and rapidly improving. - You can use one language on the back-end and front-end. You can even use the same language to write desktop, embedded, command-line and curses applications. - `babel` drives the adoption of new features into the language with greater vigor than many other languages. - The VM is very fast due to lots of work by Google, Mozilla, etc. There's also methods of interacting with modules written in WebAssembly or if you're on the back-end native modules written in Rust/C++. - JavaScript is driving a lot of momentum for new programming languages (Reason, Elm, PureScript, etc) since as a transpilation target it gives you access to many environments and libraries at the get-go. In my opinion JavaScript in 2017 is a much better language than JavaScript in 2012. I wouldn't call it objectively good but I certainly wouldn't call it 'objectively bad'. There are many reasons to choose it beyond the syntax and semantics of the language itself, and there are effective treatments available for most of the warts it was once known for. It's dominating because of the sheer drive within the community, and if there were award ceremonies it'd be winning 'Most Improved' year-upon-year.
blipblop 9y ago
> but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. What language is not flawed? And why are we "screwed"? I don't get this FUD...there are more important things than language-choice such as dependency management system + community + ecosystem. JS lets you get on with the job and get things done quickly. You need performance - use C/C++ bindings. Its been clear for a long time that JS is the safest long-term choice and is slowly creeping into every other language's castle.
- throwaway7645 9y ago
  It doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.
  - deleted 9y ago
    [deleted]
  - marcosdumay 9y ago
    > that our ancestors will have to deal with You meant descendants? Anyway, they won't. They will throw away the garbage and rewrite anything good they find. Just like we do.
    - throwaway7645 9y ago
      Haha, yes my goof up. I disagree that they will rewrite though. Nobody is willingly rewriting millions of loc.
- d13 9y ago
  It's flawed because 99.999% of the time your code will work just fine. Job done. Then one day, "undefined is not a function" and your airplane falls out of the air.
aaron-lebo 9y ago
It's really not that bad. Modern JS isn't ideal but it has many parts of it that are as good as or better than Ruby or Python, but most people don't act like they are horrible languages. I'd gladly use it over either.
d13 9y ago
Unforuntately JavaScript is the present and, yes, we're screwed.
harimau777 9y ago
What causes you to say that JavaScript is a flawed language? Not trying to be snarky or saying you're wrong, just want to better understand your reasoning. It seems to me that at one point JavaScript had a lot of confusing/bad design decisions but that more recent changes have largely eliminated them. For example, I almost never have to worry about "this" anymore. I recently worked on a project using TypeScript and I really appreciated how it changed a lot of the bugs from being runtime to compile time. I could definitely see how that is a big flaw, but it seems like the community is developing solutions.
- trgv 9y ago
  I don't think "this" in JavaScript was a bad design decision. The bad decision was how functions create their own scope in unexpected situations. Also, I think modern JavaScript still requires a lot of "this," just much less ".bind(this)" or "var that = this." But the thing is, just because arrow functions exist doesn't mean people are going to use them. Similarly, just because modern browsers allow "let" and "const" doesn't mean people will stop using "var." I agree that JavaScript is generally fine if you stick to the new parts of the language, but that in itself is a pretty big problem. Maybe not for me and you, but for software development in JavaScript generally it's really not ideal.
- throwaway819 9y ago
  https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
ryanmarsh 9y ago
type safety is becoming a hugely desired feature for developers again I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two. Now we’re finding a happy medium with compiler type inference and people are like, wait what?
- mrkgnao 9y ago
  The response to the recent Rich Hickey talk definitely points toward "dynamic typing as its own solution" (instead of a stop-gap until someone makes static typing less "verbose") being a popular view nowadays. https://news.ycombinator.com/item?id=15464423 https://news.ycombinator.com/item?id=15464423
- smaddox 9y ago
  Dynamic typing is objectively much more flexible and easier to prototype in. Static typing is much easier to build large and robust systems in. Eventually we'll get to the point where everything you can do in dynamicly languages can be done in staticly typed languages (more verbosely), but we're not there yet. For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. This is actually, IMHO, one way Go strikes a happy balance between static and dynamic typing. It provides a (runtime) safe and low-verbosity way to write dynamically-typed code, i.e. `interface{}`. Rust is slated to get something similar with `impl Trait` values.
  - tom_mellior 9y ago
    > For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. Look at this verbose OCaml: type my_return_type = AFloat of float | AnInt of int | AString of string;; let my_fun n = if n < 0 then AString "negative" else if n == 0 then AFloat 0.0 else AnInt n # my_fun (-4);; - : my_return_type = AString "negative" # my_fun 0;; - : my_return_type = AFloat 0. # my_fun 42;; - : my_return_type = AnInt 42 (But yes, to use these values you have to do pattern matching, and if you're in a FUD mood, that is "runtime downcasting" and incurs a "cost of safety".)
marcosdumay 9y ago
About WYSIWYG, we are missing standards on our APIs. SOAP was going that way but it was way too much, way too early. Either that, or an ASP.Net view where the backend is interacting with the user through a browser. But that doesn't work well. It's much better to standardize the backend API than the entire frontend.
- aphextron 9y ago
  >SOAP was going that way but it was way too much, way too early. I think SOAP successfully demonstrated that rigorous "API standards" are a pipe dream. Swagger/REST is probably as good as it's going to get.
flavio81 9y ago
>* If that's the future, we are screwed as an industry.* Agree 100%. However, i find Javascript pretty good for quick and dirty "MVPs".

pjmlp 9y ago

> WYSIWYG web design (a la Dreamweaver) died off .... Which is why what we actually need is a la Delphi

mseri 9y ago
Interesting. Can you elaborate more?
- pjmlp 9y ago
  Imagine WebComponents finally becoming mature and having a programming environment for RAD on the Web, using toolbox with drop-in components for doing application development. There are already some attempts at it, for example https://anvil.works/ https://anvil.works/
tluyben2 9y ago
I have been thinking about that and there is an issue with it; Delphi (and VB) where written in a time when devs paid a lot for software tools. Besides some niches (embedded) that is not really the case anymore. You expect to pay a few $10 at most in total if that. And a lot of people (but that might be the HN/Reddit echo chamber) demand all to be OSS as well they work with. Making 'a modern Delphi' is a lot of work; years of it. And much of that time is not 'fun', it's hard work polishing little parts and having user test groups feedback on it and polishing it some more. The time that you could be Borland seems gone (unfortunately imho) and i'm not sure how you can make the kind of polished tool you are talking about in the current climate. Maybe someone else here has some different views though.
- pjmlp 9y ago
  There are companies trying it though, https://anvil.works/ https://anvil.works/ https://www.outsystems.com/platform/ https://www.outsystems.com/platform/ JetBrains is probably a good example of a "Borland" like company. Outside HN/Reddit bubble that are plenty of companies that are willing to pay for software, the supermarket cashier doesn't take pull requests. Also, the back to native focus on mobile platforms, including Google having to integrate Android apps on ChromeOS, might make it less relevant, given that native IDEs do offer some Delphi like experience.
  - tluyben2 9y ago
    Outsystems and Jetbrains are these examples but on the other hand they are not; they are 'old'; they both exist since 2000 and at that time pushing into the market was a lot easier. I was more thinking of a company starting now, to which I'll check out Anvil.Works. There are more new companies working in the space, for sure, but they all miss the breadth that Borland had (they really had a lot of cash and developers on hand in those days). But yes, Outsystems (I worked with them and their product quite a lot in the past) could be considered a Delphi. But still not modern; it's rather painful building apps/sites with it that people seem to want. Jetbrains can be considered a Borland; I didn't think of that because I consider them more in the space of 'low level' programming tools (which, like you say, includes Delphi functionality, but a modern Delphi wouldn't be like the old Delphi; it would need a lot more innovation).
ako 9y ago
There's a healthy market of RAD/lowcode tools similar to Delphi these days. One example is Mendix: https://www.mendix.com/application-platform-as-a-service/ https://www.mendix.com/application-platform-as-a-service/ Full visual development, runs on a scala runtime, can be deployed (visually) on cloudfoundry, docker/kubernetes, etc.
- pjmlp 9y ago
  Thanks for the heads up, one more for my list. :)
boznz 9y ago
Funnily enough I was looking at the title and just thinking in 25 years time I will still be programming in the same three languages C, Pascal/Delphi and SQL I learnt 25 years ago.

tluyben2 9y ago

> Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language Everybody is everybody who has used other languages intensively or is into programming languages or, the most negative parties against JS, people who are into formal methods. But 'everybody'; I get often downvoted to hell for being negative on JS on Reddit. And i'm not using a baseball bat; i'm subtle about it as I don't care for language wars. Use what you want, but please don't say it's the best thing to happen to humanity. But no; 'everybody' (as in headcount) thinks it is the best thing that happened to humanity and that other languages should die because you can write everything in JS anyway.

PaulRobinson 9y ago
I said 'almost everybody'. Even the most ardent JS fans I work with call it objectively bad.
- aaron-lebo 9y ago
  What are their objective measures?
  - SiVal 9y ago
    I can think of one: the fraction of design decisions that the language's creator, standardizers, and serious developers wish they could change but can't.
- lhnz 9y ago
  It's hard to be objective on this. A modern JavaScript engineer would point out that: - The community is very accepting of new engineers. - The ecosystem is huge and there are great solutions available to many problems. - It's easy to write consistent code while avoiding many problems with the language if you use `eslint`, `prettier` and `flowtype`. Tooling on the web is excellent and rapidly improving. - You can use one language on the back-end and front-end. You can even use the same language to write desktop, embedded, command-line and curses applications. - `babel` drives the adoption of new features into the language with greater vigor than many other languages. - The VM is very fast due to lots of work by Google, Mozilla, etc. There's also methods of interacting with modules written in WebAssembly or if you're on the back-end native modules written in Rust/C++. - JavaScript is driving a lot of momentum for new programming languages (Reason, Elm, PureScript, etc) since as a transpilation target it gives you access to many environments and libraries at the get-go. In my opinion JavaScript in 2017 is a much better language than JavaScript in 2012. I wouldn't call it objectively good but I certainly wouldn't call it 'objectively bad'. There are many reasons to choose it beyond the syntax and semantics of the language itself, and there are effective treatments available for most of the warts it was once known for. It's dominating because of the sheer drive within the community, and if there were award ceremonies it'd be winning 'Most Improved' year-upon-year.

blipblop 9y ago

> but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. What language is not flawed? And why are we "screwed"? I don't get this FUD...there are more important things than language-choice such as dependency management system + community + ecosystem. JS lets you get on with the job and get things done quickly. You need performance - use C/C++ bindings. Its been clear for a long time that JS is the safest long-term choice and is slowly creeping into every other language's castle.

throwaway7645 9y ago
It doesn't bother you that huge portions of our tech stack are sitting on top of layers of terrible language design that our ancestors will have to deal with? Perhaps the parent post is looking more to the future. Of course it all still works, but when you think we could be doing the same job with Lisp, Smalltalk, (insert any non perfect, but much better than JS technology), it does make me cringe a little.
- deleted 9y ago
  [deleted]
- marcosdumay 9y ago
  > that our ancestors will have to deal with You meant descendants? Anyway, they won't. They will throw away the garbage and rewrite anything good they find. Just like we do.
  - throwaway7645 9y ago
    Haha, yes my goof up. I disagree that they will rewrite though. Nobody is willingly rewriting millions of loc.
d13 9y ago
It's flawed because 99.999% of the time your code will work just fine. Job done. Then one day, "undefined is not a function" and your airplane falls out of the air.

aaron-lebo 9y ago

It's really not that bad. Modern JS isn't ideal but it has many parts of it that are as good as or better than Ruby or Python, but most people don't act like they are horrible languages. I'd gladly use it over either.

d13 9y ago

Unforuntately JavaScript is the present and, yes, we're screwed.

harimau777 9y ago

What causes you to say that JavaScript is a flawed language? Not trying to be snarky or saying you're wrong, just want to better understand your reasoning. It seems to me that at one point JavaScript had a lot of confusing/bad design decisions but that more recent changes have largely eliminated them. For example, I almost never have to worry about "this" anymore. I recently worked on a project using TypeScript and I really appreciated how it changed a lot of the bugs from being runtime to compile time. I could definitely see how that is a big flaw, but it seems like the community is developing solutions.

trgv 9y ago
I don't think "this" in JavaScript was a bad design decision. The bad decision was how functions create their own scope in unexpected situations. Also, I think modern JavaScript still requires a lot of "this," just much less ".bind(this)" or "var that = this." But the thing is, just because arrow functions exist doesn't mean people are going to use them. Similarly, just because modern browsers allow "let" and "const" doesn't mean people will stop using "var." I agree that JavaScript is generally fine if you stick to the new parts of the language, but that in itself is a pretty big problem. Maybe not for me and you, but for software development in JavaScript generally it's really not ideal.
throwaway819 9y ago
https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

ryanmarsh 9y ago

type safety is becoming a hugely desired feature for developers again I don’t think anyone ever hated type safety, I think they hated verbose syntax and unfortunately conflated the two. Now we’re finding a happy medium with compiler type inference and people are like, wait what?

mrkgnao 9y ago
The response to the recent Rich Hickey talk definitely points toward "dynamic typing as its own solution" (instead of a stop-gap until someone makes static typing less "verbose") being a popular view nowadays. https://news.ycombinator.com/item?id=15464423 https://news.ycombinator.com/item?id=15464423
smaddox 9y ago
Dynamic typing is objectively much more flexible and easier to prototype in. Static typing is much easier to build large and robust systems in. Eventually we'll get to the point where everything you can do in dynamicly languages can be done in staticly typed languages (more verbosely), but we're not there yet. For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. This is actually, IMHO, one way Go strikes a happy balance between static and dynamic typing. It provides a (runtime) safe and low-verbosity way to write dynamically-typed code, i.e. `interface{}`. Rust is slated to get something similar with `impl Trait` values.
- tom_mellior 9y ago
  > For example, functions that return a different type depending on the values passed in are a useful pattern, but not allowed in staticly typed languages, except those with dependent types (Idris) or runtime downcasting (Go). There's always a way to acheive the same thing, but usually at the cost of safety or much more verbosity. Look at this verbose OCaml: type my_return_type = AFloat of float | AnInt of int | AString of string;; let my_fun n = if n < 0 then AString "negative" else if n == 0 then AFloat 0.0 else AnInt n # my_fun (-4);; - : my_return_type = AString "negative" # my_fun 0;; - : my_return_type = AFloat 0. # my_fun 42;; - : my_return_type = AnInt 42 (But yes, to use these values you have to do pattern matching, and if you're in a FUD mood, that is "runtime downcasting" and incurs a "cost of safety".)

marcosdumay 9y ago

About WYSIWYG, we are missing standards on our APIs. SOAP was going that way but it was way too much, way too early. Either that, or an ASP.Net view where the backend is interacting with the user through a browser. But that doesn't work well. It's much better to standardize the backend API than the entire frontend.

aphextron 9y ago
>SOAP was going that way but it was way too much, way too early. I think SOAP successfully demonstrated that rigorous "API standards" are a pipe dream. Swagger/REST is probably as good as it's going to get.

flavio81 9y ago

>* If that's the future, we are screwed as an industry.* Agree 100%. However, i find Javascript pretty good for quick and dirty "MVPs".