Hacker News Reader

One of the reasons why I switched from C++ to C professionally (I do C for living) was build times: previously kind of big casual game took 5-10 minutes to compile and around 10-20 sec incremental build, and now my C project takes 5 second to compile from scratch and around 1 second to do incremental changes.

Another reason being that I don't need to waste time discussing and arguing which OOP patterns to use - in C it more or less fixed how you write code. Of course one can go extra mile and reinvent VTable and Dependency Injection, but it feels all foreign to C.

So maybe give C a try, it's amazingly fast to compile and link, yet you feel almost at home after C++.

How do you cope with the lack of template containers? That's the big thing I miss in C.

Great question! To make things even more annoying - C doesn't have namespaces. So people are forced to write long names like "my_struct_hash_map_t" everywhere, which makes all modern C code look like wall of text (compare too older style code "mshm_t*a = hmalloc()"). To answer honestly - I'm asking myself very pragmatic question: "do I really need a generic code?" much more often compare to C++. In game development C++ templates were used mostly for math libraries (2d/3d/4d vectors, matrices, etc) and containers (hashmap, lists, etc). If we look closely on math libraries we can make a compromise "just float is enough", and if we make such compromise then everything is simple - one don't need templates for math lib anymore, I'm currently using "gb_math.h" [1] and it works pretty good. Containers on the other hand are more challenging, the key here is to understand "can I make this work with linear (maybe static) array?" - and in most cases yes, then you don't need any containers because just arrays will do. If algorithm specific do require a hashmap or list, well, gonna use what we have: macro! It looks weird, and it is weird, but something like khash.h [2] works fine in production.

In reality what it means for me is that I need to spend time making decisions about containers, which is good for game development, as what makes games fun doesn't have any connection to templates. But it also bad for casual non-game related code. I find it much faster to just "hey load this json, do some processing, and save json back" do that in Python than trying to do in C just for sake of C. Ideally namespaces/templates and operator overloading in C would solve all this struggles, but then where C ends and C++ starts?

- [1] https://github.com/gingerBill/gb/blob/master/gb_math.h - [2] https://github.com/attractivechaos/klib/blob/master/khash.h

There's a bizarre lack of interest in CS in the psychology of usable systems - either for developers or for users - which takes into account practical requirements like cycle time.

A lot of CS seems to be story-telling: "This feature makes language X better/worse, because it just does, obviously" with no independent testing or peer review of language productivity and robustness in real work environments.

Well then, so much for it being Computer Science...

As-is, CS really is much closer to a branch of mathematics than a science.

Eh, in a similar way to how theoretical physics is mostly math. Math is the tool you're using, but the assumptions are all based on real-world observations.

I don't know about that; real world observations like what?

Like observations of what can and can't be computed by physical objects. The point of the Church-Turing thesis is that things you prove about Turing machines are proofs about what you can compute in the real world, not just some abstract mathematical model.

Since computers are built by people for people, it does seem like we're missing the most important and difficult science in favor of doing the science that's easy to do. It's easy to reason about how a system that I designed will perform. It's hard to answer the questions of how our technology choices affect other people. It would be great if science could help us design high quality systems with a limited budget, or establish a theory around whether designing any given system will improve someone's life. It would be pretty dang useful if we had some formal scientific results around what makes a game fun, or more generally what makes software pleasant to use and productive.

> establish a theory around whether designing any given system will improve someone's life

That would be sociology or one of its siblings, no?

... or, at best, the piddly "ethics" course that gets tacked on to most undergraduate CS degree programs?

I think that's why Go is so popular right now. I find the language kind of depressing from a PLT perspective, but it was built taking into account practical requirements such as fast compile times, a standard formatting tool, ease of deployment, etc, which makes it a very good system.

Fortunately, computer science still literally means just that - it's an exploration of the properties of computers. As to humans developing computer based systems, yes, scientific rigor is not mandatory, just as you don't require understanding classical mechanics to build an abode. As to the psychology at play with humans developing and using computer based systems, rigorous psychology is eminently suited to your concerns.

I would like you to cite some papers, which claims it makes language X better/worse without any explanation.

> to working in a lousy language with very, very fast turnaround. [...] The PHP "builds" as fast as I can refresh a browser page.

This observation ("workflow") was one of the 3 bullet points outlined by Keith Adams' 2013 presentation "Taking PHP Seriously".[1][2]

(KA's presentation was partially a response to 2012 "PHP a Fractal of Bad Design".[3])

Basically, the horrendous inconsistencies and flaws outlined in "PHP Fractal Bad" can be true ... but simultaneously be overshadowed by "workflow" benefits.

[1] starting with slide #14 of "Adams-TakingPHPSeriously.pdf" : https://github.com/strangeloop/StrangeLoop2013/tree/master/s...

[2] 4 previous HN threads: https://hn.algolia.com/?query=php%20seriously&sort=byPopular...

[3] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

I have been using TypeScript. The TypeScript compiler gives me roughly 1-2 second builds, even on a large project that (it can watch code and build incrementally).

So I get the benefits of static types, plus the benefits of fast iteration, PLUS the benefits of a fully dynamic language for when I want to accomplish something quickly.

It's a full win-win-win. Throw in linting to avoid the legacy JavaScript crap and it's pretty awesome.

> The PHP "builds" as fast as I can refresh a browser page

JavaScript is just as fast, or faster. That's probably an important reason why it's "eating the world".

So is python, which is a much nicer language.

You don't know what you're talking about. Python process needs to be bounced, or has to watch files and bounce itself on change. The PHP runtime is designed to read the file on each request. You have to go out of your way to require restarts (it is an optimization). PHP has the only mainstream runtime AFAIK that is designed this way (+ the model is stateless, so each refresh really is one). I'm not a PHP fan but it bothers me that people don't acknowledge some of its important, unique features and are content to rag on its inadequacies. It bothers me because we're probably ten years from people forgetting what PHP was, and creating a new, worse PHP (!).

This message would have been just as effective without the opening accusation.

Sorry, you're right, I was annoyed by the "hurr durr Python" tone.

It didn't even have that tone...

Well it does just assert without any supporting argument that Python is a nicer language, which is textbook flame-war starting.

Your assertion that giving an opinion without supporting evidence is automatically "textbook flame-war starting" is also patently silly.

Python can reload modules while running. This is standard practice. And anyway, bouncing a Python process is instantaneous.

Sorry, when I said "Nicer language", i meant that it has a more readable syntax.

On top of that, I was comparing Python to JavaScript and wasn't even talking about PHP, which, as you rightly discovered, I have very little knowledge about.

I agree that JavaScript is fast - but we've ruined that in a lot of places by throwing in things like code genertion, compilation, builds, and other nasty words. The turnaround for the last React&Node program I had the displeasure of working with was on average 30 seconds.

PHP - for all its faults - does not suffer from these kinds of recompilation issues, yet can be optionally pre-compiled for added speed when you do go to production.

I don't use backend js, but things like webpack-dev-server which on file save do an incremental recompile and then hot reload have made this a non issue on the frontend for me. Not sure if this applies to your use case, but figured it couldn't hurt to offer a partial solution.

On the backend side, tools like nodemon provide a very similar solution. Then just setup your webpack server to proxy requests to your backend, and you're good to go.

No its not. It's slower.

TDD can help with this. I more often than not, will write a unit test or functional test first, then work on the code for that test where I'm just running that one test until it succeeds. After I have individual parts working, I will integrate everything, which again will just be another integration test run from the IDE.

I realize this isn't always possible, and is probably easier to do in a managed language, but you can cut down on iteration times by mostly forcing the IDE to do incremental compiles. You can work in real-time on code that might take tens of minutes for a full build.

TDD is fun.

Despite being downvoted, this assertion about TDD is true. It can provide a very interactive experience when programming, even with languages with little natural interactivity. But you have to know how to set up the tests.

I'm enjoying wallabyjs with jest and vscode. It's quite fun having feedback from test execution always available in the IDE.

I don't have a long build step for my codebase (compiling typescript just takes a few seconds and incremental is instant) -- but I do avoid lengthy deployment cycles -- deploying code to aws lambda takes quite awhile.

A good IDE will go a long way here. Any of the IntelliJ IDEs are interactive in almost any aspect of technical coding. Setting up and running a test is a left click, if you've written the function and annotated it in Scala. I've been trying to use Atom for some embedded coding, and some of the plugins for it are pretty good, but not completely free. MS VS is up there too, but I haven't used it in a long time.

Off course, writing testable code using OO almost requires dependency injection IMO. With FP, it's almost trivial.

have you ever tried BDD (behavior driven development)? one of the interesting aspects of this is being able to develop the test implementation in a different (possible more expressive) language

For web development, yes. Once you know pretty much what you want, and have a good idea of how you're going to go about implementing it, it can be fast. If you're new, don't know what you want, and are starting out on a framework, it can be an impassable chasm. If you're just experimenting, it's also a bit too much.

Starting with a simple unit test or spec (what I meant by functional testing, though this can be BDD too) can be easier to start with and change as you figure out what you want. Even with specs, or a BDD framework like you said, no need to bring in a whole new DSL unless you need it IMHO, others may disagree.

I've never done professional Web Development. But, I found BDD useful for describing correct behavior to the end user in a readable, yet functional and extensible way. When it works well, it eliminates the telephone game of capturing requirements and translating into brittle test cases which are readable only by the developers.

It's true, but it's more a treatment then addressing the root cause.

Rich Hickey, creator of Clojure has a fun quote that goes something like: "You thought you wanted TDD, but really you wanted an interactive REPL."

My gripe with TDD, is that it gets tedious in its own way. Always needing to eventually mock some aspects of the code, and always working in the small, you start feeling distant from the medium and large picture of the code.

It's a pretty good treatment. I think the solving the root cause would be something like a constant time compiler, which I don't think is going to happen. You don't need to mock at all if you do DI and modularity well in Guice or Spring or something else (it can be the rare exception for a few libraries that use say private constructors). You can also write 3-5 line tests that will absolutely test everything in your program, and be able to debug it line by line in a debugger. So, I'm not sure I would agree with Rich Hickey on this. REPLs are no substitute for a good IDE and debugger running a series of declarative tests.

Not all REPLs, just like you had to preface debugger with good, you need to preface REPL with good. You really need to give a good REPL a fair try to know what I mean. Most people also thought tests wouldn't add much worth, and took a long time to bother giving tests a fair chance. Good interactive REPLs are the same. Try it out, not one day of it, spend a week, then decide. It helps if you know someone that can show you. At my work, a lot of devs try Clojure and don't like it. Then I sit down with them and show them how you're supposed to use the REPL. They always turn around after that, and acknowledge how awesome the REPL is. That's why I emphasize on fair chance. Its easy to try it and miss the point, not use it how it is meant to be used. Also, the language must embrace it, if its tacked on, it rarely works. It has to be first class.

Ya, I agree, tests are a good treatment, the best for most languages. A good interactive REPL is often better though. Clojure has tests, good IDEs and debuggers. Yet people don't care about them as much, because the REPL solves most problems. In return, it means the IDEs and debuggers aren't as good as Java, because people care less and so also invest less in them, and sometimes I'd want a better IDE or debugger to complement the great REPL experience, but I wouldn't trade the great interactive REPL for them.

A REPL is better when prototyping but tests have a lot of value afterwards. They're repeatable and they can be used to spot regressions.

I think that the a good workflow is to do initial experiments on a REPL followed, once I get an idea of the code will look, by writing tests and the actual code that will run in production.

Yea, you still want regression tests no doubt, but those are very different from TDD. You only need write them after you're code complete on a feature.

While I agree with the first part (immediate feedback is essential), I'm not sure about the connection with LISP in the end.

Doesn't LISP offer the same "fast feedback" cycle that e.g. PHP or whatever does? And even faster than C++?

It's kind of my point: LISP does (mostly) provide instant feedback, but it's not used much in the real world (every big LISP success I've heard of wound up either being translated into a shlub language, or resulted in the teams using it having a really hard time hiring people and scaling).

Ya, I think that's just the familiarity hump. Most people don't get over it, and the few that did geek out too much about the possibility of infinite macros, and how you could extend Lisp, while eventually realising how few made it past the familiarity hump and starting to feel isolated they eventually move to something else.

It's hard to break this habit of familiarity, it's self replicating, because the less familiar people are, the less likely they can have good teachers and teaching material about it, etc.

I spent months working on a Lisp project in college. I pretty much hated it.

Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery.

After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.

>Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators

Is it that "Some people" don't like those, or that "some people" have been to Algol-style languages first, and they can't easily adapt to the other style?

>Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of mastery, and I've learned more than a dozen to a high level of mastery.

Yes, but I bet the first one's you've learned were already algol-like.

After that, adding other languages does not mean much if they all share the same paradigms and syntax style. It's like a Common Lisp person also learning Scheme, Racket, Clojure etc -- in the end it's not much difference.

Going from those to different paradigms is what makes an actual difference (e.g. learning Coq, or Erlang, or Haskell, or Lisp or Forth, etc).

people's exposure to infix operators way precedes any dabbling with an algol language; it's the common notation that everyday mathematics has settled upon. you learn it in school.

>Yes, but I bet the first one's you've learned were already algol-like.

BZZZZT! Wrong answer!

I started with BASIC and transitioned from there to assembly language. Wrote several games and device drivers in assembly language (BASIC was too slow) and then learned Forth. Tried really hard to like Forth, and played with it for a while; loved some aspects of the language, but couldn't wrap my head around how to write a game with it, so I gave up and kept writing games in assembly language.

Pascal was my next language, and that wasn't until later. Much later than that I finally got to C.

You might think of BASIC as Algol-like, though I'd say it's more Fortran-like. Assembly language, though, is about un-Algol as a language can be, as is Forth.

Some would go to fight with a Long Sword, others would prefer a Katana. I think that's fine. Master what works best for the way your mind and body works. That said, I'd hate for languages to adopt a lowest common denominator just so companies feel then that all programmers can replace any other and all code base is understandable by all. That would be like having every sword fighter fight with a knife.

After a while you have to stop blaming the people and instead just admit that Lisp isn't as awesome-for-all-purposes as some famous people seem to think it is.

I don't know, sounds like it's just not as awesome for you, but probably is that awesome to all those famous people saying it is.

I spent months working on a Lisp project in college. I pretty much hated it.

Like I said, its possible the style doesn't bode with ya, and that's cool. That said, here's my anecdote. I also did Lisp in college and hated it. Thought it was stupid, had the worst most unreadable syntax I'd ever seen. It made every trivial thing hard, like why can't I just loop?!?, where are the variables?!?, how do I just do one thing followed by another?!?. Where do things start and end?!? I don't even remember what Lisp it was, but trust me, it was some academic cryptic variant, probably maintained by some teacher himself, had no library ecosystem, lacked documentation, the ugliest editor I'd ever seen. Anyways, moved on and never thought of it again.

Then became a dev, did C++, some assembly, moved to ActionScript 3 lots of event programming, then C#, JavaScript, Java, all that. Suddenly, I gave Lisp another shot, at work, on a real project, not some school project, with Clojure. First thing I realized, there are libraries and documentation, and frameworks, you can set variables, loop, do infix even if you want too. There's easy ways to do imperative code, OOP, all that is there, I just couldn't see it before, I think it was college shadowing the obvious from me, and maybe my coding instincts weren't good enough then, so I couldn't recognise things if they looked and behaved slightly differently. Also, I had coworkers who used Lisp for real projects, commercially. I realised Lisps are often used in school for teaching theoretical programming concepts. But in practice, you'd not use Lisps like that, you'd use it like any other language. Anyways, eventually, I also got recursion, tail call, collection mappings, pure functions, higher order functions and all that. Once I got all these things, it was like, how have I had been using anything else before. Now its such a drag to go back.

>I don't know, sounds like it's just not as awesome for you, but probably is that awesome to all those famous people saying it is.

Like our pg? Who loves Lisp to death, and made his first major app (a web page store generator, if I recall) in Lisp? But then after selling it to Yahoo -- ported it to another language (Python?) so that other developers could actually modify it?

It's not "lowest common denominator" to expect a language to stay within certain bounds of flexibility. If every single project has so many macros that it's effectively a DSL that no other programmer anywhere understands, then you've created a software package that becomes instantly unmaintainable if the wrong people get hit by a bus.

In college, by the time I picked up Lisp, I had already used:

* Assembly Language * Basic * Pascal * Forth * C++ * Recursion

And I'd already worked on video games professionally (in 1987, in a project for Lucasfilm Games, before they became LucasArts).

Java and C# had yet to be invented. At the time, there weren't libraries and documentation to speak of in any Lisp, so that's something. It was Common Lisp (as well as "elisp" on the Atari ST, which of course was completely incompatible...).

Since then, I've used tail calls (in Lua, and soon coming to JavaScript), collection mappings, pure functions, higher order functions, and all that, in many other languages. I just still hate Lisp, and while I have no problem understanding how to use Lisp, I don't see the advantage of using it over using other languages, and in particular I am finding static types to be critical in large system architecture, which are completely lacking in Clojure and other Lisps.

1987, wow, I have to give you my respect. I think then Lisp is just not your thing, but I have to ackownledge that in 1987 they might have sucked. Realistically, the only one I like and know is Clojure and ClojureScript. Maybe I'd hate Common Lisp if I tried it. I know I don't like elisp, because it doesn't even use lexical scope by default, that's just a nightmare.

I don't see the advantage of using it over using other languages

That's probably the best question to ask, I think sometimes there's a lot of false benefits to new/different tools, that while cool, rarely add real value.

My observed (but not measured) benefit was enhanced productivity. That said, I'm not sure how much of that is due to Clojure being a Lisp, or more that I switched from Java/C# which are staticly typed and verbose, to a dynamic language. I don't encounter the issues I do in JavaScript and Python (which I have experience with) as much with Clojure though. Mostly that they get harder and harder to maintain over time. Again, I'm not sure this is because of Lisp, I feel it's more due to Clojure's choice to be a functional language first, with default immutability and managed reference types, as well as its smart choice of abstractions, like open polymorphism using protocols and multi-method and CSP instead of event hell.

The only thing I feel are benefits brought over from Lisp are the interactive REPL workflow, concise notation, code that can be used as an extendable serialization format and configuration format, as well as macros (as double edged sword). Macros have helped me in rare times, to avoid having to write verbose code, but at my work we have very few macros even after 2 years of accumulated code, I think we added 5 or 6 macros only. And I wouldn't want to have more, for the reason you mentioned, we're not looking to use our own custom programming language, and add too many macros and that's what you get. By the way, Clojure chose to not have reader macros, which other Lisps have, and are the ones where you can really go crazy changing the very syntax.

I'd be just as fund of another language that would be functional, immutable, interactive and with smart abstractions. I can live without macros, even though I love a good macro when you need one. I would prefer a syntax with only expressions, not a fan of statements, because you're restricted on where you can use them. And I like concise syntax for having to type less and read less, able to see more at once. I reckon not all Lisps fits this description, so maybe its really not Lisp I should evangelize, but Clojure specifically. Elixir also fits this description, that I know of.

On static vs dynamic type systems, I still don't know. I like types, they feel good to have, but I just don't feel they really help, I think they're a false sense of safety, and they just slow you down. That said, maybe they pay back in the long term maintainance, I'm still unsure though.

> I'd be just as fund of another language that would be functional, immutable, interactive and with smart abstractions.

You get all of the above with TypeScript except immutability. Pull in Lodash for extra functional sauce, or the functional variant of Lodash for increased composability. And the serialization format is the industry standard JSON.

Events are really a necessary tool. You're the first person I know of to complain of "event hell;" event-based programming is a key feature of modern operating systems and browsers and applications. I haven't used a CSP (it looks like a Lisp thing?), but it doesn't look like a full replacement for events, but rather streams? And there are functional stream libraries in JavaScript/TypeScript. [0]

I don't deny that having macros as a "sometimes feature" would be a good thing. I just can't stand the Lisp zillions of nested parenthesis. (Thankfully JavaScript callback-hell is also a thing of the past with async/await and Promises...I don't like zillions of levels of callbacks either).

I think once you have static types, immutability isn't as critical, but if you're set on it, there's always Immutable.js [1]

> On static vs dynamic type systems, I still don't know. I like types, they feel good to have, but I just don't feel they really help, I think they're a false sense of safety, and they just slow you down. That said, maybe they pay back in the long term maintainance, I'm still unsure though.

Technical debt earns compound interest over time. Static type systems let you zero out technical debt for almost no effort.

The only "slow you down" I get from TypeScript is defining declarations for libraries that are missing them. That's about 5 minutes to 15 minutes per library. That's an extremely low up front cost to pay, and everything else about TypeScript is faster (auto complete on object members) and better (refactoring is fast and easy enough that it's easy to "just do it" and not put it off until later).

[0] http://reactivex.io/ or https://github.com/cujojs/most/ are good examples.

[1] http://facebook.github.io/immutable-js/

Ya, I would probably be happy with TypeScript. How's the backend story? Is using it with node easy? Is there an interactive mode, or just quick transpilation?

It's pretty trivial to use with Node. You just need to have a source folder, set up your tsconfig.json file with your preferred options, and then run:

    tsc --watch

There's also an REPL for Node here:

    https://www.npmjs.com/package/ts-node

I find it a bit tricky to do anything complex in, though. Since TypeScript is mostly ES2015 anyway, when I want interactive anything I usually just use an ES2015 interpreter (like Node itself). The types usually make interactive stuff more challenging.

Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk.

The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!

It sounds great in theory, once those tools are delivered, but in practice you've lost more than you gained. No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.

What I say about image based tools also applies to code deployed in a database. Good luck keeping source control in sync with stored procedures...

Fair enough, but not all Lisps are image based. Clojure is file based. That's the one I use.

> No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools.

I bet people said the same about trains and ships. There was a lot of work put into horse-powered infrastructure and first cars and trains were very slow and bad. Same with boats: at the time steam-powered ships were created wind-powered clippers were 5 times faster and much more reliable.

The difference here is that image based languages have been making the argument that their better will beat every one else's larger community for decades. The one that came closest to realizing the dream was Smalltalk.

But somehow it never happened.

>The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image!

First, what's bad about that? Our text editors and source control systems are indeed crap compared to what we could get with image based systems with inherent (not text-level) knowledge of code. The only real argument is that we still need to work with legacy crap text-based languages also, which can't share those tools. But that's not really an argument against those tools being good in themselves.

Second, there's nothing about an "image based language" that says you can't also have a textual representation, and thus work with your editor (or the image based editor) and "regular" SCM tools.

Third, LISPs are generally not image based.

You are right that in principle an image based system should be able to produce a better tool for dealing with that environment than is possible with a text based system.

However no image based system is poised to take over the world. And I'm willing to bet my salary that none will ever have sufficient mind share to do so. Programmers switch languages, environments and operating systems. When you add switching tooling to the learning curve, you've just created a barrier to entry to the environment, and programmers are going to spend time learning something that is not applicable to whatever else they do next.

So you wind up with using "awesome tool if you just understood it" where your hires don't. And the "awesome tool" probably isn't quite what those people find most productive. So it becomes a constant frustration.

Move back to a text based language, and this problem goes away. People use the tools that they know. I'm probably going to write code in 4 different languages this week, and have to look at what is going on on a half-dozen machines..and won't need to switch tools.

On having a textual representation, yes you can do that. And then you've changed your image based language into just being yet another VM for another language. Whether you write code in Java, JavaScript or Python in the end it runs in a VM, and that doesn't matter.

As for LISPs in general, it depends. What I've seen with Lisp has mostly been image based, but I don't use Lisp very often.