Hacker News new | past | comments | ask | show | jobs | submit login

I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions as arguments! Macros! Type inference! But now, barring macros, these features are all in mainstream languages.

If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde.

Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly. It's the Foo Fighters of languages. Cool, but not irresponsible.

[1]: I was in a very famous tv show: https://www.youtube.com/watch?v=FBw-Z8ULwcc




The big difference between Rust and OCaml is that a company the size of Jane Street can influence OCaml development, while it takes one the size of Amazon (according to the recent accusations) to do the same with Rust. I think OCaml has one of those "ancient" communities that seem to value independence more than consensus. Rust is very hard to build without cargo, OCaml works fine with make or dune. I'm not sure if focusing on independence is the right tradeoff for most companies, but I can see some cases where it might be.

> If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE.

IDE support is getting there with OCaml. In VSCode, it's not as good as TypeScript but it's usable.

> Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde.

There are a few libraries that you can use. Serde also tends to make the already long compilation time blow up.


I was writing code in the 90's, and my first IDE was Turbo Basic in 1990 precisely, followed by Turbo Pascal alongside Turbo Vision and Object Windows Library.

Eventually I also got into Turbo C, Turbo C++, and then upgraded myself into Borland C++, used Visual Basic 3.0 in 1994, and a couple of years later Visual C++ 5.0 was my first MS C++ IDE.

Mac OS MPW was an IDE and stuff like AMOS and DevPac were IDEs as well.

Java IDEs started to show up around 1998, like Visual Cafe and the first Eclipse, after being ported from IBM's Visual Age.

Visual Age, which were the IDEs for Smalltalk and C++ from IBM for OS/2 and Aix.

The only group that wasn't using IDEs were the UNIX folks, thankfully XEmacs was around to bring some back sanity when I had to code in UNIX.


I'm curious about these early IDEs. My knowledge of 90's programming is solely from secondary sources. What features did they have? Did they do stuff like automatic renaming or goto definition? Were those features done syntactically or semantically? How fast were they? A common complaint I've read is that people could type faster than an IDE could keep up, which is something I rarely encounter these days.


Clojure has access to the Java library ecosystem and works beautifully in IntelliJ. That may be one of the best ratios of language properties to tooling quality.


Cursive brings it some Lisp Machines development workflow love as well.


It doesn't work in IntelliJ unless you use Cursive, though?! Which is not free (has that changed??).


Free for personal use IIRC.


A couple points:

These days, you don’t need to build an IDE from scratch - you can just build some language server support for your language and plug into existing IDEs. It’s much less work!

Also, as an aside that’s not really germane to the argument, it’s possible (and IMO preferable) to write code without using an IDE. It forces you to write code that’s broken up into contexts small enough to fit in human working memory. This pays off in the long run. However, once people in your company start writing code with an IDE, it requires more context and becomes almost impossible to edit without an IDE.

Haskell is another language besides OCaml that doesn’t have a ton of MEGACORP backing but nonetheless forms the basis for several very successful companies and groups within MEGACORPs, and where many developers prefer the experience of using it despite not having a $10M IDE like you would for Java. And speaking of that, all the ludicrously expensive and complicated IDEs mostly suck anyway!

> you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE

I wasn’t writing code in the 90s, but I’ve worked at places like this and I would take it any day over “people who copy/paste from stack overflow and get lost without autocomplete” - unless the novel alternative you have in mind is something better than that?

> Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly

Rust does seem to be in the schelling point of “better enough than C++ to get us off our asses, but no so much better as to scare the devs”. Not sure I’d say it’s especially “responsible” though.


Language servers are certainly a big improvement. However there's a different between "there exists" and "this is a community priority". In some language communities the developers use IDEs, they like IDEs and they make IDEs a priority. In other communities there's one or two people who like them, kinda, and maintain a plugin. Let's put it this way, I don't see OCaml moving to a query based compiler anytime soon.

I'm not sure I agree with the no-IDE part. It feels very "Plato complaining about the invention of writing". Human working memory is quite narrow and quite fickle. If you step away from a codebase for a while, or you're learning it for the first time, an IDE can really help with your bearings. I agree that code should be broken up into contexts and well organized, but I don't think the editor should be the forcing function here.

And IDEs are great! Goto definition that works even in complicated situations unlike ctags; inline type inference; generating imports. I don't begrudge someone using emacs or vim (2nd generation emacs user) but I gotta say, IDEs work wonders.

As for who I'd recruit, I think it's a false dichotomy to say that the alternative is "people who copy/paste from stack overflow and get lost without autocomplete". There's plenty of great, legit developers who can write you a custom serialization library in nano, but choose to use IntelliJ and packages because it gets the job done.

I don't mean to denigrate the OCaml, Haskell or Lisp communities. I wish more people wrote them! But I also recognize that these languages went from secret weapons to, well, a valid option in a trade off matrix. I'd still love to work at Jane Street, although between this comment and my application record, that may be a pipe dream.


> Also, as an aside that’s not really germane to the argument, it’s possible (and IMO preferable) to write code without using an IDE. It forces you to write code that’s broken up into contexts small enough to fit in human working memory

No, complex programs by definition don’t fit into human working memory. Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level — so in the end you will end up with larger chunks of code for which you will have to use code navigation features - for which I personally prefer an IDE, but that is subjective.


> No, complex programs by definition don’t fit into human working memory.

If you write your code in the right way they don’t have to. That’s the point.

You shouldn’t need to comprehend your entire program at once to work with it.

> Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level

Function composition isn’t the pinnacle of abstraction. We have many other abstraction techniques (like rich types, lawful typeclasses, parametric programming, etc.) which allow for any given subcomponent of a program to be conceptualized in its entirety.


> If you write your code in the right way they don’t have to. That’s the point.

I recommend you try working through some equality proofs in Coq, first with and then without coqtop / Proof General. I think you may change your mind about this rather rapidly. And many proofs get much more complex than that.


I’ve used (and developed) plenty of proof assistants. Proofs are one very narrow domain where automation is basically a no-brainer. You don’t really lose out from the proof having high semantic arity. With normal code, you do lose out.


I dunno. I think the line between "normal code" and proofs is a lot blurrier than many people make it out to be, and I don't think there's a huge advantage to asking people to run a type checker or inference algorithm in their heads even if you have managed to encode all your program's invariants in the type system (which is impossible or impractical in many languages). I say that as someone who doesn't use an IDE except when I'm forced to: I know I lose out on a lot of productivity because of it, and I don't find that removing the IDE forces me to develop better or more concise code.


What if the program is a hundred million floating-point values, produced by learning?

Can you look at them in small chunks to understand what they are contributing to the result?

It looks like there is such a thing as complexity that is not functionally decomposable.


Do you write your programs like a neural network? I would consider that a major red flag when hiring.


I can work without autocomplete, but I find my productivity is about 20% when I have to go back and forth with the compiler on syntax errors and symbol names, like back in college. Working professionally with an IDE that just doesn't happen.


I would call Microsoft Research part of a MEGACORP.


PG seems to be the only person who has built a successful business using Lisp. While thousands of successful companies are using C++/Java/.. etc. why do you think so few companies have succeeded with Lisp?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: