proj-oot-ootNotes39

---

kaba0 7 hours ago [–]

> For example properties are relatively easy to implement, but instead developers decided to implement records which are very different

But why would they bake in a misfeature? Yeah it is popular, but was never a good idea to begin with. Records and new language features try to slowly shift the focus to a more immutable, FP-oriented style of OOP, which is imo a good decision. Of course it doesn’t make imperative code legacy, the two worlds can coexist perfectly.

> Modules are weird thing that nobody asked for

This is the feature that allows the JDK team to do their work. You either expose the internals and freeze it, effectively killing the platform, or encapsulate it. It is/was a great decision, and it didn’t broke too many things.

reply

jcadam 7 hours ago [–]

I think Kotlin is pretty much what a modernized Java should be. Between it and Clojure I don't spend very much time with Java anymore.

reply

jackcviers3 7 hours ago [–]

Kotlin could he better, but doesn't go all the way. Without HKTs and implicit injection, Java is going to eat its lunch. Java already has records, type inference, parametric null safety with Optional, Loom provides coroutines, vavr and streaming apis have given us theabilitytodo FP... what's left as a unique feature?

Kotlin will survive because it was picked for Android to avoid copyright issues. But the difference between the two languages is vanishing small.

reply

cutler 15 minutes ago [–]

Dream on. Java, even including upcoming features, has nowhere near what's included in Kotlin out of the box. Nullability? Extension methods? First class functions? I could go on. Kotlin is much more than a better Java.

reply

nine_k 1 hour ago [–]

When Java gets the Kotlin's brilliant "last argument of lambda type can be a block", let me know. It allows to massively extend the perceived syntax of the language where needed, and create nice, typechecked DSLs. A number of small ergonomic improvements is also impossible to port to Java.

And I'm definitely happy that Java does not feature implicit injection, which looks so cool but is so painful to work with in Scala.

When I need HKTs, I can pick a perfectly good Haskell :) I'm afraid Java or even Kotlin will never achieve this level of FP-ness; for that, a language should be designed differently. Rust, OTOH, likely will.

reply

cutler 13 minutes ago [–]

Agreed re Scala's implicits. They've just repackaged them for Scala 3 as given/using but it's the same confusing nonsense that drove me away from the language.

reply

---

strictfp 7 hours ago [–]

Java development scales, it has pretty good performance, and great tooling.

I agree that it's underhyped. You can pick a lot of other languages, but no other language is as broad as Java.

Python reads like a dream but has useless perf and threading.

Javascript (Node et al) has the I/O concurrency but no clear solution to threading, and is bad at number crunching.

C++ has good perf but is overly complicated, compiles take forever, no good module management, etc.

Rust is great but super-hard to learn.

Golang lacks tooling and perhaps some libs, albeit being a really good contender.

Naturally there are other languages to bring up, but I personally think that Java strikes a good balance. The language itself doesn't really have any clear weak points anymore. With lambdas and streams, even FP is succinct in it.

The only thing really speaking against Java right now is the culture of overly complicated frameworks with too much meta-programming and magic. And the fact that the market of lightweight alternatives is too fragmented.

reply

dehrmann 5 hours ago [–]

> great tooling

Something I underappreciated until I delved deeper into other languages is how much observability the JVM gives you into how an application is running. Something like VisualVM? makes it incredibly easy to see what threads are running, in what state, etc.

There's a class of things where the overhead of a VM (like the JVM, not VMWare) doesn't make sense (kernels, drivers), and startup time can be an issue, but for code where pretty good performance is enough, running in a VM is an asset to me.

reply

---

maxpert 7 hours ago [–]

I’ve already moved to Kotlin. I love the language other than the fact that JVM objects are just too heavy. Nothing against Java but language has aged like milk, the readability and writability is just too bad. Recent strides with records and project loom etc are evident efforts to make it evident again.

I’ve kinda started to like Kotlin from syntax perspective & Go’s nature of compiled and low overhead prospective. I wish somebody can combine those together (don’t tell me GraalVM?).

reply

---

BiteCode?_dev 14 hours ago [–]

For my use cases, Java has all the wrong compromises:

So why use Java ? It's good, it's fast, it's productive, it's well supported, battle tested and documented for decades with a huge pool of devs. And many companies already use it and the tooling is excellent.

But those are not sufficient reasons for me.

Python is older than Java, well supported, battle tested, documented with a huge pool of devs. But it's way better for high level stuff, data mangling, scripting, gluing, and for most web dev stuff.

If I want a distributed system or something with a lot of I/O, Erlang and Go will always be better than Java. Sure, they are less widespread, with all the stuff it implies, but for such a nice need, I will pay the price hapily: my goal is optimization for the use case. Same for stuff that needs to go fast or have a small footprint, I'm not going Java if I can go Rust.

If I want to have fun, Java is out of the loop. Better sharpen my inner weirdness by fighting with some exotic lisp. Why try productive ? I wanna enjoy myself, not run a business.

So Java is not a bad choice. It's an excellent tech. I just don't have a use case for it.

reply

goto11 9 hours ago [–]

Your premise is that you are able to chose a language based on how appropriate it is for a specific use case. This alone shows you are not the typical user of Java!

Java is typically used in larger or long-lived organizations. It is rare to start new projects from scratch. Most development is maintenance and extension of existing systems. Even if you start a greenfield project, it would be most prudent to chose the same platform and language which is already used in the organization. An alternative language would not only have to be better, it would have to be very significantly better to make up for the overhead and headache in maintaining code in multiple languages - never mind the increased difficulty in hiring and training developers.

Geeks tend to evaluate language based on how appropriate they would be for a greenfield project with no organizational baggage. But this is an extremely rare use case for most business.

HN often has reports about startups rewriting everything from scratch every four months, when a new language or platform becomes fashionable. But this is not the world where most developers live.

reply

BiteCode?_dev 1 hour ago [–]

Yes of course, don't fix what's not broken.

It's orthogonal to my point though.

reply

---

 wwn_se 13 hours ago [–]

Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all.

Java is like you say not the greatest at anything but it is also not the worst at anything. Its great for projects where the you don't know what you should optimize for or don't care.

If java is to boring maybe kotlin is the way to go. I really like kotlin and in my personal experience the only downside is that the IDEs is not as good as the java counterparts yet.

reply

---

wwn_se 13 hours ago [–]

Python projects that start to grow has a tendency to become hard to manage in a way that I have not seen in Java at all.

Java is like you say not the greatest at anything but it is also not the worst at anything. Its great for projects where the you don't know what you should optimize for or don't care.

If java is to boring maybe kotlin is the way to go. I really like kotlin and in my personal experience the only downside is that the IDEs is not as good as the java counterparts yet.

reply

mnw21cam 12 hours ago [–]

I write software in Java. I can't stand python - too wishy-washy.

But my main complaint about Python is trying to use someone else's software. Then it degenerates into a maze of twisty little passages of trying to install the correct set of dependencies, not knowing where those files are installed (which makes it difficult on a cluster, as you may need to do the install on every node separately). Then you try using pip and it fails because some element of what it is trying to install isn't compatible with your operating system for reason 1. So you try anaconda instead, and that fails in a different way, like it runs a C compiler on some file (!?) which fails because $REASON. I have numerous examples of Python software where I have followed the (detailed, precise) installation instructions, and it doesn't work.

Whereas with Java, you just dump the necessary jars into a directory, include them in the classpath, and it works.

Don't get me started on R.

reply

BiteCode?_dev 12 hours ago [–]

I came to say say that's not a language problem, that's a packaging problem. But that would be misleading.

The reason packaging is still a problem in Python are linked to the language:

So yeah, compared to Java, Python packaging and distribution sucks.

But compared to rust all packaging and distribution for all languages do, so there is that.

reply

---

habosa 22 hours ago [–]

I haven't been coding as long as most (about 10 years) but I've had phases of Java, Ruby, Python, JS, TS, ObjC?, etc.

If I go onto my GitHub? and try to get any of my old projects running I am extremely confident that the non-Android Java ones will still work. All of the other ones will probably have "rotted" over the years and send me down a day-long rabbit hole looking for old dependencies or build systems.

There's something to be said for that amazing stability. I can't think of another language where you can find some .edu page from 2001 with a link to a library (.jar) that does what you need and you can actually use it in a modern application.

reply

---

thiht 1 day ago [–]

> Java is fun to write, productive

What the hell? I don't think we have the same definition for any of these words.

I know Java has changed quite a bit since Java 8 (Java 9 being the last version I used professionally before switching completely to Go), but I just can't write Java again, it's physical. When I want to try a new Java feature and think about writing the scaffolding code, my stomach actually hurts.

Not to mention the pain point that it still is to install and configure a JDK, and make it work properly with Intellij, why is it still so complicated?

Then there's Maven and Gradle that are just... bad, I have no other phrasing. I hear a lot of people saying Maven already solves all the problems we have with today's tools but that's just not true, even the entire Maven stupid lifecycle should be thrown away!

reply

Twirrim 1 day ago [–]

> Not to mention the pain point that it still is to install and configure a JDK, and make it work properly with Intellij, why is it still so complicated?

I used to work for a company that had about 100 different Java web applications running, each with their own JDK. It was _trivial_ to set up and maintain. Was it wasteful? Sure. I shipped a JDK with each application. Was it hard to automate? No. Basic deployment automation made it trivial. The JDK was just an application artifact alongside the JAR file, and the application starting script set JAVA_HOME pointing to it for that process.

IntelliJ? makes it trivial to maintain a project specific JDK. You just add the location of your JDKs to it (IIRC it can even auto-populate the list), and then choose the JDK from a simple menu within the IDE.

reply

---

zzzz898 1 day ago · edited 1 day ago

    This cannot be understated: Java simply feels good to write. A lot of this is due to the craftsmanship JetBrains puts into IntelliJ IDEA. Everything is autocompleted, jump-to-definition is fast, find-usage works well, and refactoring is easy. However, where Java truly shines is the developer experience with third-party libraries.

This is true, but you pretty much have to use a complex IDE, because Java is incredibly verbose.

    There are a number of disadvantages with dynamic/duck/weak/whatever typing. When a dependency changes an API method and your application fails at runtime rather than build time that's a problem.

Sure, Java is quite robust compared to JS and other dynamic languages, but not enough compared to languages like Scala, OCaml, Rust and others.

    Java developers can confidently trust the JVM to do what's best. Whether they're implementing a multithreaded application or storing a large amount of data on the heap, they can be confident they won't shoot themselves in the foot with memory management or data races. This advantage is primarily in comparison to C++, which contains a multitude of footguns.

Java performance is... okay ? I guess. But you will still need a language like C/C++/Rust/Zig/Ada... to write extremely performant code.

I dislike the "everything has to be a class", "100 lines per file" and "10 lines per function" mentality that some Java programmers have - it makes navigating the codebase a nightmare.

---

snej 27 hours ago

link flag 
    Yes, yes you can technically use a fairly restricted subset of C++ or whatever and then you can avoid some C-isms at the cost of risking runtime panics on the new operator.

If you’re referring to compiling with exceptions disabled, you avoid such crashes by using the nothrow variant of operator new, so an allocation failure just returns a null pointer.

There’s really no cost to using “C++ without exceptions and RTTI” relative to using C. Right now I’m working on a project for an embedded ARM32 device with 20KB of RAM and about 200KB ROM, and I’m doing it in C++. I’m using classes, references, and a few templates, but zero heap allocation, not even using the C standard library. Currently it’s about 30K of code and a couple hundred bytes of global data.

---

fierro 2 days ago

parent flag favorite on: Pulumi 3.0

the problem isn't necessarily in the abstraction. It's in the language design. Terraform (HCL) started off as a declarative language. Then people wanted string concatenation. Then conditionals. Then modules. You end up with this kludge of a language that benefits from none of the foresight of having been designed as a general purpose programming language from the outset -- no unit testing, poor control structures, etc.

---

http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small/ suggests that hot code swapping is not really a good fit for most scenarios

---

13 zeebo edited 23 hours ago

link flag 
    This is interesting and I am prolly going to use it in our services. Could you talk more about the underlying protocol?

The wire format used is defined here. https://pkg.go.dev/storj.io/drpc@v0.0.21/drpcwire

Logically, a sequence of Packets are sent back and forth over the wire. Each Packet has a enumerated kind, a message id (to order messages within a stream), a stream id (to identify which stream), and a payload. To bound the payload size, Packets are split into Frames which are marshaled and sent.

A marshaled Frames has a single header byte, the varint encoded stream and message ids, a varint encoded length, and that many bytes of payload. The header byte contains the kind, if it is the last frame for a Packet, and a control bit reserved for future use (the implementation currently ignores any frame with that bit set).

Because there’s no multiplexing at this layer, the reader can assume the Frames come in contiguously with non-decreasing ids, limiting the amount of memory and buffer space required to a single Packet. The Frame writing code is as simple as appending some varints, and the reading code is about 20 lines, neither of which have any code paths that can panic.

    How it is a drop in replacement if both client and server needs to be changed

There’s a drpcmigrate package that has some helpers to let you serve both DRPC and gRPC clients on the same port by having the DRPC clients send a header that does not collide with anything. You first migrate the servers to do both, and can then migrate the clients.

The drop in replacement part refers to the generated code being source code API compatible in the sense that you can register any gRPC server implementation with the DRPC libraries with no changes required. The semantics of the streams and stuff are designed to match.

Sorry if this was unclear. There’s multiple dimensions of compatibility and it’s hard to clearly talk about them.

---

"

Les Nouvelles Années Folles

After careful analysis, the language of the 2020s might as well be (and maybe already is) Rust, a language that achieves the rare feat of satisfying both high- and low-level programmers alike.

Rust shows many, if not all, signs of modernity:

It is open source, hosted on GitHub?, and we all know that open always wins.

It features generics, and they are at the base of optionals used to solve Sir Hoare’s conundrums.

It does not feature inheritance, instead relying on composition.

Likewise, it does not rely on exceptions for error handling, proposing a handy Result generic type instead.

It does not have a garbage collector, instead controlling reference lifecycles and ownership during compilation.

It includes popular functional programming constructs, like lambdas, map/filter/reduce, and even better, with a “lazy” behaviour inspired from Haskell.

It has a free book and an online playground to learn the language without having to install anything in your local machine.

Even though it uses type inference to make code look like scripts, it has such a strong type system it can fight buffer overruns at compile time.

It can be installed in the terminal by piping a script downloaded with curl from the trusty interwebz.

It includes a ready-to-use library of algorithms and abstractions, appealing to both system and app developers as well, in a “batteries included” kind of approach. And if you do not find what you need, just use its own package manager called cargo and access to a large array of contributed code; for example, an ORM, a GUI, or an image processing library.

It features built-in unit testing.

Its variables are immutable by default.

It has macros, an intelligent evolution of C macros mixed with C++ template metaprogramming.

Primitive arrays include the length as part of their type, and can be easily initialized in the same line.

Its compiler generates blazingly-fast code, and it can do cross-compilation. It can even generate standalone statically-linked binaries, ready for use in Docker containers. Heck, it can even generate WebAssembly? out-of-the-box. With a bit of luck, it might generate climate change-friendly binaries.

It has its own annual developer conference, aptly named RustConf?, a weekly newsletter, a dedicated Awesome Rust page in GitHub?, and lots of questions and answers on Stack Overflow.

It uses curly brackets, and anyway, the rustfmt tool removes the risk of conflicts around code formatting style preferences.

It does not feature a goto keyword, respecting Dijkstra’s commandment.

In short, Rust ticks many checkboxes in the modern category. " -- [1]

---

    2
    jec 7 months ago | link |
on: state-transition tables

State transition tables are awesome for building parsers. The J word formation algorithm is defined as a state transition table that translates closely to static C arrays.

I took influence from that in my own work-in-progress toy language where I represented the lexical state transition as an array of strings in Rust:

/* Word formation proceeds by interpreting the lex class data with a small tokenizing state machine.

Code State Description
------+------------+-----------------------
'^'Start Start of input
'#'Ignore Comment delimiter
'/'Comment Body of comment
'@'Atom Numeric array value
'_'Space Array spacing
'+'Symbol Symbolic token
'x'Name Alphanumeric name
'&'Conjuction Punctuation delimiter
','Text Literal characters
';'Quote Escape literal text
'$'Accept End of input

---

https://wiki.alopex.li/ThingsWeGotRight

Just pondering a few of the things that became so conventional in programming that we don’t care about them anymore. Nice to reflect upon when considering the shitshow of design decisions in the modern computing stack.

    Integer representation – two’s complement
    Floating point – IEEE 754
    Byte endianness – not universal, but basically settled on little endian for processors and I only foresee it becoming more universal with time. Network protocols are big-endian by default but that’s at least well defined, and not enough of an impediment to matter
    UTF-8 – Going to have a hard time coming up with a better variable-length integer representation that prefers small integers. There’s others that are just as good, or better for some purposes, but UTF-8 still has some nice properties.

---

" Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal). " -- norvig

---

"

norvig on Oct 18, 2010

parent favorite on: Ask PG: Lisp vs Python (2010)

Peter Norvig here. I came to Python not because I thought it was a better/acceptable/pragmatic Lisp, but because it was better pseudocode. Several students claimed that they had a hard time mapping from the pseudocode in my AI textbook to the Lisp code that Russell and I had online. So I looked for the language that was most like our pseudocode, and found that Python was the best match. Then I had to teach myself enough Python to implement the examples from the textbook. I found that Python was very nice for certain types of small problems, and had the libraries I needed to integrate with lots of other stuff, at Google and elsewhere on the net.

I think Lisp still has an edge for larger projects and for applications where the speed of the compiled code is important. But Python has the edge (with a large number of students) when the main goal is communication, not programming per se.

In terms of programming-in-the-large, at Google and elsewhere, I think that language choice is not as important as all the other choices: if you have the right overall architecture, the right team of programmers, the right development process that allows for rapid development with continuous improvement, then many languages will work for you; if you don't have those things you're in trouble regardless of your language choice.

"

---

" I would want the ability to restrict the standard library and builtins (no I/O) a la Lua. " [2]

---

embeddable languages:

lua, moonscript, fennel, fe, guile, any forth core, pocketlang

(via https://lobste.rs/s/g8ossq/pocketlang_small_fast_friendly_language#c_wgmqtp )

--- 210626

yknow i kinda feel like i could just go and write the initial implementation now. When i started thinking about this i couldn't easily envision how all the parts would fit together and now i feel like i can (i'm sure actually doing it will reveal a vast gulf of remaining ignorance). In contrast, now i kinda know:

and i have an idea of the basic lower-level architecture that i want to start with:

and then:

and i have an idea was Boot and BootS? will look like.

of course i dunno when i would ever actually have time to write an implementation. And i doubt whatever i come up with will ever be good enough for even me to use. And even if it was i doubt it would be better than the alternatives enough to have made it worth spending the time to make. And even if it was i doubt i'll have time to properly maintain and expand it.

---

" HTTP Server Performance

We continuously track the performance of Deno's HTTP server. A hello-world Deno HTTP server does about 25k requests per second with a max latency of 1.3 milliseconds. A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and 300 milliseconds.

Deno's HTTP server is implemented in TypeScript? on top of native TCP sockets. Node's HTTP server is written in C and exposed as high-level bindings to JavaScript?. We have resisted the urge to add native HTTP server bindings to Deno, because we want to optimize the TCP socket layer, and more generally the op interface.

Deno is a proper asynchronous server and 25k requests per second is quite enough for most purposes.

" [3]

---

https://xenodium.com/emacs-smarter-search-and-replace/

" But what if you'd like to feed the match to another function? You can use \, to signal evaluation of an elisp expression. In other words, you could multiply by 3 using \,(* 3 \#&) or inserting whether a number is odd or even with something like \,(if (oddp \#&) "(odd)" "(even)"). "

~ johnaj 22 hours ago

link flag

This neat feature is very reminiscent of the /e flag of Perl regexes:

s/re/arbitrary perl expression/e

It’s incredibly useful in some cases. I use it in my inc script, which increments numbers inside lines given on standard input.

---

https://news.ycombinator.com/item?id=22865357

nicoburns on April 14, 2020 [–]

Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example:

---

"There are efforts to define the behavior in cases where implementations have converged or died out (e.g., twos complement, shifting into the sign bit)."

7532yahoogmail on April 14, 2020 [–]

I agree which brought me into looking at Zig. A future version of C might disallow macros, preprocessor, disallow circular libraries, include a module system, but allow importing legacy libs like Zig. Also something like llvm so we can automatically do static analysis, transforms would be great.

---

ori_b on April 14, 2020 [–]

> - Some kind of module system, that allows code to be imported with the possibility of name collisions.

That doesn't particularly need modules -- just some form of

     namespace foo {
     }

---

wahern on April 14, 2020 [–]

So I just reran some tests on my existing VMs and it turns out I remembered wrong. Here's the actual break down:

Note that all the above lengths are exclusive of NUL, and the passed socklen_t argument did not include a NUL terminator.

For posterity: on all these systems you can still create sockets with long paths, you just have to chdir or use bindat/connectat if available. My test code confirmed as much. And AFAICT getsockname/getpeername will only return the .sun_path path (if anything) used to bind or connect, but that's a more complex topic (see https://github.com/wahern/cqueues/blob/e3af1f63/PORTING.md#g...)

---

cperciva on April 14, 2020 [–]

When will C gain a mechanism for "do not leave this sensitive information laying around after this function returns"? We have memset_s but that doesn't help when the compiler copies data into registers or onto the stack.

pascal_cuoq on April 14, 2020 [–]

This is an entire language extension, as you note. The last time various people interested in this were in the same room (it was in January 2020 in a workgroup called HACS), what emerged was that the Rust people would try to add the “secret” keyword to the language first, since their language is still more agile than C, while the LLVM people would prepare LLVM for the arrival of at least one front-end that understand secret data.

Is this enough to answer your question? I can look up the names of the people that were involved and communicate them privately if you are further interested.

---

sramsay on April 14, 2020 [–]

I'm pretty happy with C as it is, but I will admit to being surprised that a "minimalistic Rust" hasn't risen to prominence.

I guess what I mean by that is a language that has Rust's hyperactive, strongly opinionated compiler, borrow checker, no NULL, immutable by default, etc, but in a language that is no more syntactically ambitious that C89. I would be way more into a language like that than Rust.

A language that sort of feels like Go, but can actually be used for low-level systems programming.

Leherenn on April 14, 2020 [–]

I think it's going to arrive, but some time is needed to see what works in Rust or not. D is going this way as well, so should provide another data point.

---

watergatorman on April 14, 2020 [–]

Some random thoughts:

I appreciate the original simplicity of K & R, "The C Programming Language", 2nd Edition, and the relatively simple semantics of ANSI C89/ISO C90 compared to C99 and later.

You don't need complex parsing methods for ANSI C89/ISO C90 and you do not need the "lexer hack" to handle the typedef-name versus other "ordinary identifier" ambiguity.

---

oldiob on April 14, 2020 [–]

Is the committee planning on working on the preprocessor? I don't see any reason for not boosting it. It's time for C to have real meta-programming. Would be nice to have local macros that are scoped.

On another note:

Finally, stop putting C++ craps into C.

---

~ talideon 1 hour ago (unread)

link flag

I don’t hate Perl, but I’m deeply ambivalent towards it. It had a niche which was basically “imagine if we took awk, sed, and shell scripting and turned it into something resembling a proper language”, and to be fair, it managed to do a lot with those foundations. But it never quite outgrew them, and the last attempt to do so almost killed it as a language.

For text munging, few languages come close, but I haven’t felt the need to reach for it in over a decade.

---

kragen on Feb 13, 2020 [–]

Well, most mainstream languages are dialects of Lisp (though usually with syntax, records, methods, and sometimes static typing) so if you strip them down far enough you get Lisp. Other reasonably usable minimal programming languages do exist, like the lambda-calculus, the pi-calculus, Abadí and Cardelli's object calculus, the ur-Forth, and the ur-Smalltalk, but they're not as familiar.

---

kragen on Feb 13, 2020 [–]

Well, most mainstream languages are dialects of Lisp (though usually with syntax, records, methods, and sometimes static typing) so if you strip them down far enough you get Lisp. Other reasonably usable minimal programming languages do exist, like the lambda-calculus, the pi-calculus, Abadí and Cardelli's object calculus, the ur-Forth, and the ur-Smalltalk, but they're not as familiar.

---

on live coding:

" "Yeah yeah," this hypothetical skeptic might say, "so there's a REPL. So what? Ruby has that. Python has that. Heck, even Haskell has that."

To this paper-thin critic I rebut: "Ahh, that may be, but none of those languages offer true interactive development."

True interactive development is programming by directly working on your program as it runs. As you do, you find yourself recompiling functions, methods, and whole classes, on the fly. Each change you make is immediately and automatically a part of the live program. When you are programming interactively, you are not so much writing code as sculpting and structuring live computer memory.

True interactive development is also about programming in such a way that your program never crashes. Instead, whenever an unhandled condition is raised, the program starts an interactive debugger. While interacting with the debugger you don't lose any program state, not even the ephemera of the call stack, unless you choose to do so.

...

Again, true interactive development is programming such that

    your program never crashes
    because it enters an interactive debugger
    where you never lose program state
    unless you choose to do so
    after a thorough inspection of state
    including the call stack
    and after you have tinkered, recompiled functions, and edited objects
    and after you have tried restarting the computation
    all while the live program is running, possibly remotely.... Interactive debugging is part of the Common Lisp standard, so you can always count on it being there. Interactivity is supercharged, however, by tools like SLIME, SLY, and the wire protocol that gives them life, Swank. It is by using something like SLIME that you gain the "true interactivity" that I celebrate somewhat haughtily above. "

---

ppl really want monkey patching for tests:

https://esoteric.codes/blog/bouk-monkey-satirical-code-used-by-people-who-dont-get-the-joke

---

How different programming languages read and write data

https://opensource.com/article/21/7/programming-read-write

---

i like most of the critera for early Rust:

Project Servo - Technology from the past come to save the future from itself

---

http://venge.net/graydon/talks/rust-2012.pdf also a good read, altho i don't think it's appropriate for oot (we don't care about perf)

---

http://venge.net/graydon/talks/CompilerTalk-2019.pdf notes that ML-style or Lisp-style languages are good for writing compilers in

http://venge.net/graydon/talks/CompilerTalk-2019.pdf notes that 80% of optimization perf can be gained by these 8 optimization passes: "The ~8 passes to write if you're going to bother. •Inline, Unroll (& Vectorize), CSE, DCE, Code Motion, Constant Fold, Peephole ... Many compilers just do those, get ~80% best-case perf. " -- [4]

http://venge.net/graydon/talks/CompilerTalk-2019.pdf notes the following compilers with smaller LOC written in an ML-like or Lisp-like language:

random joke programming language highlighting some things that the author dislikes about Golang:

https://github.com/jesseduffield/ok

---

bityard 10 months ago [–]

I haven't written any Tcl in years but one of the things I liked about it was that it's not deep at all. Very simple rules, with enough flexibility built-in to (usually) make it do what you want.

zests 10 months ago [–]

I want to get to the point where I'm comfortable using what makes Tcl special like uplevel/upvar. I can use it as a basic scripting language but I don't really grok what makes it special.

Its like knowing how to use lisp but not knowing how macros work. Funnily enough this is actually where I am now with lisp.

MaxBarraclough? 10 months ago [–]

Sounds like the Forth philosophy.

---

http://kmkeen.com/tiny-code/ (another link to this that i randomly came across: http://kmkeen.com/tiny-code/2009-02-20-12-00-00.html )

---

sgeisenh 17 days ago [–]

I would like the definition of "boring".

Most of my day job is spent reading C++ (I write some, too) and it is more terrifying than boring. Understanding when certain errors can (and do) occur and when to optimize for performance over readability is really, really hard.

I believe that Rust, Go and TypeScript? have gained a lot of popularity because they are boring to read. Even OCaml has gained a ton of popularity because it is boring to read.

C, C++, python and JavaScript?: not boring to read, you constantly need to be on your toes.

silisili 17 days ago [–]

If there's one thing I've learned on the topic in my life and career, it's that everything written should be written for the reader, not the writer. Perl, C, and C++ are very much for the writer. To some extent, Rust also.

Python and Go are good for the reader. These aren't exhaustive lists, just what I'm familiar with. Admittedly, Python is tricky because it looks simple(boring) at first glance, but lets one use a lot of magic.

My daughter is learning cursive and it just reminded me how much I blasted hate it. I can write it fine, reading it is a tossup. It's solely a shortcut for the writer, at the expense of reading. But anything of importance is read thousands or millions more times than it's written.

In programming especially, the easier to read the better, no matter how verbose and boring the language. I think we'll get there, when we all quit pretending we're too clever to write that way.

lmm 17 days ago [–]

I find people make the mistake of thinking about how long it takes them to read 20 lines rather than how long it takes them to read x piece of functionality. (Of course it's much harder to compare the latter, but that's like the drunk searching for his keys under the streetlamp rather than where he dropped them). If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read? Well, maybe, but if those 200 lines are replacing 20,000 lines of Go, then maybe not.

pharmakom 17 days ago [–]

Python is hard to read at scale in my view. There are no mechanisms for managing state effectively. Long procedures that mutate globals can be very difficult to follow.

kamaal 17 days ago [–]

Python is hard to read if you use vim and don't use something like lsp.

IDE's make languages like Python really easy to read. Plus these days you also have type hints in Python as well.

Seirdy 17 days ago [–]

"IDE features are language smells"

-- Reg Braithwaite

kamaal 16 days ago [–]

Yeah, Ideally we should all be using Common Lisp. But let's not go down that debate again.

---

example of why you often find you want a turing-complete language even when you think you only need a 'scripting' language:

https://mailman.neomutt.org/pipermail/neomutt-users-neomutt.org/2021-March/001001.html

---

some tarot of programming languages; lazy/strict (evaluation strategy); lexical vs dynamic binding; early vs late binding; compiletime vs runtime; variable vs interpolate; type vs value;

---

https://softwareengineering.stackexchange.com/questions/724/killer-semi-unique-programming-language-features

---

could make a programming language CYOA for r/makeyourchoice

kind of a list of design priorities. Like, 'guaranteed memory safety' (like a managed language) or 'memory safety tendency' (like Zig)

---

i guess i should learn how to do these things quickly:

https://groups.seas.harvard.edu/courses/cs153/2019fa/cs153-self-assess.pdf

---

in order to allow sandboxing and not allow sandboxed code to somehow access implementation-dependent-cached values in undefined memory, could have some primitives to protect private/secret variable:

probably the 'secret' annotation is most powerful -- the compiler can then just do an implicit undef when the variable falls out of lexical scope, and can set the 'private region' to the lexical scope.

So yeah, 'secret' annotation is a good idea

---

note that our security against reading secret data is 'best effort' in the sense that we assume that the CPU does what it 'should'; if the CPU vendor and/or spec is actually saying that they don't guarantee security from attacks (eg spectre/meltdown style attacks) from code within the same OS process as the victim, that doesn't mean that we promise to put different parts of your program in different OS processes.

---

as we go up the levels of Oot implementation, from Oot Assembly to OVM to Oot Core, how we specify the behavior of invalid programs becomes more safe (and harder to implement).

---

" Btw. is their good literature about the implementation of intermediate languages as compilation targets for static functional languages? I think the book to go was SPJ's "The Implementation of Functional Programming Languages", but I am not sure how relevant it is today. "

---

"It's like a red pill, it always bugs me like "I wish I have macros here", or "type classes here", "Erlang process here", "Hindley-Millner or structural typing here".."

---

"If anything, just try a new language - Regardless of what you do, you really should explore other languages. I would recommend any of the following: Clojure, Rust, Elm, OCaml/Reason, Go, or Scheme. All of them have unique features and will force you to learn a new way of thinking."

---

"

caseymarquis on Dec 26, 2019

parent favorite on: I love coding in C

Coding in C is like camping. It's fun for a while, but eventually you really miss things like flushing toilets and grocery stores. I like using C, but I get frustrated every time I hit a wall trying to build features from other languages. C is a very WET language.

C is basically it for embedded development though. I've gotten so tired of recompiling and waiting to flash a chip with C, that I've started learning ANTLR and making my own language. The idea is to have a language which runs in a VM written in C, and allows you to easily access code which has to be in C. Sort of like uPython, except it can easily be used on any board with a C compiler with a small amount of setup, and C FFI is a first class citizen. Also coroutines masquerading as first class actors with message passing, since I always end up building that in C anyway.

diego_moita on Dec 26, 2019

parent favorite on: I love coding in C

> I've started learning ANTLR and making my own language.

> a language which runs in a VM written in C [...] easily be used on any board with a C compiler with a small amount of setup, and C FFI is a first class citizen. Also coroutines

Use Lua. It has all of that already.

caseymarquis on Dec 26, 2019 [–]

I've looked at LUA, and it's possible I missed a flavor, but I have a long list of things I want:

  -Static types that match C for seamless interop.
  -No GC
  -First class actors 
  -Ahead of time declaration/allocation of actors and messages, with automatic async-like passing on a coroutine/actor waiting for an allocation, and automatic disposal of the actor after prolonged allocation failure.
  -Hot swapping actors from a running system in the field
  -Over the wire debugging and inspection of a running system in the field

AtomVM?, an erlang VM for small devices is closer than LUA to what I'm looking for. However, I really want to create an environment made for embedded development, not try to tack a higher level runtime onto something like an ESP32 and have devices drop every 2 months from a memory leak. "

---

" rumanator on Dec 26, 2019 [–]

> Coding in C is like camping. It's fun for a while, but eventually you really miss things like flushing toilets and grocery stores.

The only issue I have with C is that there are no good reasons for some of those missing features to be missing.

Take, for example, namespaces. Would it be a problem to implement them as, say, implicit prefixes?

Gibbon1 on Dec 26, 2019 [–]

That's exactly my complaint. I think it's missing things because if you added them in a way compatible with the C way of doing things then you would permanently cleave C from C++. Since C++ is a runaway train at this point detaching is probably a good idea now.

Me I want range types like Ada. Real array types. I think I want blocks/coroutines. "

---

old Fantom post on targeting LLVM, interop:

[5]

---

Student 30 hours ago

link flag

It’s all about ecosystem. Tbh I think it’s a shame that rust is bigger than pony, not least because the explicit ownership (“capabilities”) system is much clearer than rust’s implicit model.

    ~
    timmyjose 13 hours ago (unread) | link | flag |

And also much much harder to understand (well, at least given the resources on the ponylang website). I think this is the death knell for Pony. Sylvan Clebsch is already working on Verona at MS (and I don’t think he had been contributing much to Pony over the past few years in any case).

    5
    brocooks edited 11 hours ago (unread) | link | flag | 
    at least given the resources on the ponylang website

Pony contributor here. We’re always looking for ways to improve the documentation. I admit that reference capabilities are one of the hardest things to grasp when learning the language, and if you have any ideas on how you’d prefer to see this covered, or have any suggestions on what the tutorial should cover, feel free to reach us on Zulip. We’re always happy to chat!

    ~
    Corbin 3 hours ago (unread) | link | flag | 
    Maybe Pony’s capability model was too complex. Compare and contrast with E, which has only one form of reference (the object reference) and doesn’t require callers to care about ownership. (Not to imply that E has been widely adopted.)

~ Student 6 hours ago (unread)

link flag

In my limited experience with both, I found pony much easier to understand. And yes if the two main contributors are working on Verona, I suspect language development will slow.

-- [6] ---

" nielsbot on Nov 27, 2017 [–]

Someone once suggested to me the easiest way to "bootstrap the world" is to write a Forth implementation in assembly, and then write your Lisp in Forth.

z29LiTp?5qUC30n on Nov 27, 2017 [–]

as there is a project aiming to "bootstrap the world" https://savannah.nongnu.org/projects/stage0/ and they hand wrote a FORTH http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/f... and a compacting garbage collecting lisp http://git.savannah.nongnu.org/cgit/stage0.git/tree/stage2/l...

and their opinion was that it was easier to do the lisp than it was to do the FORTH. Although right now they are trying to improve their C Compiler prototype https://github.com/oriansj/M2-Planet before they convert it to assembly "

---

my comment: we won't be satisfying this niche (we are going to make lots of breaking changes for the forseeable future) but it's good to know that it exists

drmeister 2 days ago

next [–]

I like the term "Eternal Language" - programming languages where if you write code now - you will be able to compile and use that code ten years from now (a software lifecycle eternity). Common Lisp, C, C++, Fortran, (edit: Java) are close to eternal languages. After losing a huge amount of Python 2 code (I wasn't going to rewrite it) I implemented Clasp, a Common Lisp implementation that interoperates with C++ (https://github.com/clasp-developers/clasp.git) so that I can write code that will hopefully live longer.

I am one of the few software developers with code that I wrote 27 years ago that is still in active use by thousands of computational chemistry researchers (Leap, a frontend for the computational chemistry molecular dynamics package AMBER, implemented in C).

reply

---

i like a lot of the features described in:

https://nim-lang.org/blog/2021/11/15/zen-of-nim.html

---

"Our industry has a history of not getting these second-order points. E.g. to this day I’m convinced that the primary reason why microkernels are mostly history is that everyone who jumped on the microkernel bandwagon in the 1990s poured a lot of thought into the message passing and ignored the part where the performance will always be shit if the message passing system and the scheduler aren’t integrated." -- https://lobste.rs/s/ljsx5r/flatpak_is_not_future#c_ldxerd "

---

BayleShanks RecentChanges Bayle Shanks's website
Comments on proj-oot-ootNotes39 This page is read-only View other revisions Administration
Last edited 2021-12-15 08:00 UTC by BayleShanks (diff)